perm filename BIG5.MSG[COM,LSP]7 blob
sn#873509 filedate 1989-05-22 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂03-Apr-89 0908 Quinquevirate-mailer Starting Up
To: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Folks, as usual I've started up a mailing list for this
little subgroup. Luckily there are 5 of us so I recycled
this one:
quinquevirate@sail.stanford.edu
with the archive file:
big5.msg[com,lsp]
Some might not like the imperial tone of it all, but it's simply
too much hassle to add another mailing list to the ones SAIL knows
about already.
Here is what ISO decided, which has implications for us:
1. A draft of ANSI Common Lisp shall be delivered to the member
delegations so as to arrive by July 31.
2. The draft shall be accompanied by a document that outlines how
X3J13 evaluates that draft. This is a rationale statement and should
discuss those criteria we use for judging changes made to Common Lisp
and for judging the quality of the draft itself.
3. Optionally, we can supply a document that outlines our constructive
criticism of an existing Lisp and its specification as an international
standard.
In short, the German proposal was accepted and we are now in the process
of selecting drafts/languages to possibly standardize. There is currently
some question as to how many standards will be accepted, and I have
announced to WG16 that the US will decide whether to submit both Common
Lisp and Scheme or only Common Lisp based on our guess as to which of the
paths is most likely to result in an ISO Common Lisp.
During discussions with Chailloux, he remarked that all he really wanted
was a core language that was a subset of both Common Lisp and LeLisp.
This was news to me, and during further discussion it became clear that he
was technically confused about what a core language was and so explained
the funny set of changes he proposed to Common Lisp in the so-called AFNOR
plan. I think defining a core of Common Lisp according to his intentions
is relatively simple, since it is a core language rather than an
independently useful dialect.
I believe our charter includes the authority to make virtually any
editorial decision and some minor technical decisions. The latter should
be almost entirely of the form of deriving conclusions from decisions made
by X3J13, but I can imagine making decisions about things that were
overlooked. The largest decision I can imagine us making is a compromise
on the adjust-array question if that decision is consistent with existing
practice and all that has been decided by X3J13 already. (Actually, I
don't expect we will be able to make such a decision, but it is an
example. The key point is that I think we understood what was meant in
Kauai about the resolution that passed, but that resolution was
technically flawed. We could clean up that resolution.)
I plan to do some re-writing if that is acceptable. Right now I am willing
to rewrite the history section and the sections on conditions. I am also
willing to edit those other sections where my reviews outline a lot of
problems. I think we should do this by a checkout mechanism where KC is
the locking device. That is, we should ask her to check out a file or
group of files, and when we are done, should be have the authority to
compare our version with the older one and to merge them as she sees fit.
-rpg-
∂06-Apr-89 1033 Quinquevirate-mailer Notes from 4/3 meeting
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Apr 89 10:33:03 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05156; Thu, 6 Apr 89 10:33:59 PDT
Message-Id: <8904061733.AA05156@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA05156; Thu, 6 Apr 89 10:33:59 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Apr 89 12:23
To: quinquevirate@sail.stanford.edu
Subject: Notes from 4/3 meeting
Drafting Committee meeting notes, 4/3/89, 10:30-12:30, Thinking Machines
Attendees: Masinter, Moon, GLS, Chapman
Goals:
1. Complete review/rewrite by this committee by 6/26 meeting.
2. Mail a ready-for-review draft to ISO delegations by 7/14/89
(deliver in person to French delegation to enjoy quatorze juillet??).
3. Make parts of the standard available to X3J13 as they become
reviewed/rewritten. Perhaps these will be letter ballots, or just
info copies.
4. Make complete standard available to X3J13 for review after 6/26
meeting. Accept and respond to comments until the November meeting.
5. Review this plan by 4/14/89.
Other notes:
About the standard:
1. Suggestion to can the Side Effects section. No significant disagreement.
2. Suggestion to move from section 2.2 (types) anything that has to do
with external representation to appropriate sections (3.1, 3.2, or
description of write function). No disagreement.
3. Suggestion to move processing rules from section 2.2 to a separate section.
Seems reasonable to move them to section 6.1 (Introduction to Catalog
of Defined Names) under a special subsection heading ("Rules") and
special subsubsection headings, one for each type.
4. After all the Jan and March issues are included, a guess will be made
as to which issues will pass in June, and those issues will be included.
Anyone wishing to make a stab at that list now is more than welcome. Otherwise
that list will be coming to you for review in about 3 weeks.
5. See the editorial committee report for other changes that have been
or will be made to the standard.
Administrative:
1. New draft of the standard was moved to hudson.dec.com today. It is the latest
version but with only editorial changes since March meeting (only editorial
issues and proposals included).
2. The subject of a mailing list was brought up and rejected, but RPG
had already set one up. Would you prefer I list your names, or is the
mailing list okay?
3. I will send you copies of what you need as they are finished and as
follows:
Who How What
------------------------------------------------------------------------
RPG Mail Source files and a build file.
Masinter Mail+FTP List of source files and build files.
Moon Mail+FTP+USMail Source files, hardcopy
GLS USMail Hardcopy
4. I will send the sections that are ready now while we are reviewing this
plan. If there are changes, I will remail to the proper person.
5. The original plan for this group had people working together
on certain sections. I have not listed pairings here and will wait
for you to ask me to work out those details. If you intend to change
a section that someone else has completed, please copy the person
whose section you're changing and me on the changes.
6. I won't be making changes to source files while you have them.
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application RPG 6/14/89
1.2 Organization of the Document Done
1.3 Referenced Publications Done
1.4 Definitions Done
1.5 Compliance KC 5/1/89
1.6 Language Extensions KC 5/1/89
Chapter 2. Objects and Types 4/1/89 4/14/89
CONTENTS
2.1 Introduction Done
2.2 Types Moon 5/1/89
2.3 Classes Done
2.4 Slots Done
2.5 Objects Done
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader RPG 5/1/89
3.2 Object Syntax RPG 5/1/89
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model Moon 5/14/89
4.2 Compilation RPG 6/14/89
Chapter 5. Other Topics
CONTENTS
5.1 Errors RPG 5/14/89
5.2 Input/Output Masinter 5/1/89
5.3 Interface with the Programming Environment Masinter 5/1/89
5.4 Generalized Reference Masinter 5/1/89
Chapters 6 and 7. Catalog of Defined Names
CONTENTS
6.1 Introduction RPG 5/1/89
The following list contains the names of groups of functions as they
appear in CLtL, CLOS, and the Condition System documents. For example,
Masinter is to review/rewrite the functions in Chapter 15 (Lists) of
CLtL by 5/1/89.
CLOS RPG 5/1/89
PREDICATES Masinter 5/1/89
STRINGS Masinter 5/1/89
SEQUENCES Masinter 5/1/89
LISTS Masinter 5/1/89
NUMBERS Masinter 5/1/89
STRUCTURES GLS 5/14/89
SYMBOLS GLS 5/14/89
HASH-TABLES GLS 5/14/89
ARRAYS GLS 5/14/89
TYPES GLS 5/14/89
DECLARATIONS GLS 5/14/89
IO Masinter 6/14/89
STREAMS Masinter 6/14/89
FILE Masinter 6/14/89
CONTROL Masinter 6/14/89
PROGRAM Masinter 6/14/89
MISC Masinter 6/14/89
ERRORS RPG 6/14/89
MACROS Moon 6/14/89
PACKAGES Moon 6/14/89
CHARACTERS Moon 6/14/89
EVALUATOR Moon 6/14/89
Glossary RPG 5/1/89
RPG: 1.1, 3.1, 3.2, 4.2, 6.1, 5.1, CLOS, Errors, Glossary
Masinter: 5.2, 5.3, 5.4,
PREDICATES, STRINGS, SEQUENCES, LISTS, NUMBERS, IO, STREAMS,
FILE SYSTEM INTERFACE, CONTROL STRUCTURE, PROGRAM STRUCTURE,
MISCELLANEOUS FEATURES
Moon: 2.2, 4.1, MACROS, PACKAGES, CHARACTERS, EVALUATOR
GLS: STRUCTURES, SYMBOLS, HASH-TABLES, ARRAYS, TYPES, DECLARATIONS
Sections that are ready now: 1.1, 4.1, 5.1, 5.2, 5.3, 5.4, CLOS.
It is not felt that these sections will change much as a result
of issues that haven't been included.
Note that 5.2-5.4 "passed" at the meeting, but Larry and others still
feel there is work to be done on them.
Other sections will be ready when the issues and proposals passed in
Jan and March have been completely included.
Thanks in advance for your time.
kc
∂07-Apr-89 0752 Quinquevirate-mailer ftp files
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Apr 89 07:51:05 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA07960; Fri, 7 Apr 89 07:51:30 PDT
Message-Id: <8904071451.AA07960@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA07960; Fri, 7 Apr 89 07:51:30 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 7 Apr 89 10:43
To: quinquevirate@sail.stanford.edu
Subject: ftp files
Please let me know before you take a file from hudson.dec.com for
the purpose of changing it. I will assume that I am free to make
changes in files that I have not explicitly mailed to you (or the
pointers to you) or that you have not told me you were changing.
kc
∂07-Apr-89 0759 Quinquevirate-mailer checked out status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Apr 89 07:59:31 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA08905; Fri, 7 Apr 89 07:59:48 PDT
Message-Id: <8904071459.AA08905@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA08905; Fri, 7 Apr 89 07:59:48 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 7 Apr 89 10:57
To: quinquevirate@sail.stanford.edu
Subject: checked out status
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2
3.1
3.2
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
∂11-Apr-89 0813 Quinquevirate-mailer checked-out sections
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 11 Apr 89 08:13:27 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00365; Tue, 11 Apr 89 08:13:59 PDT
Message-Id: <8904111513.AA00365@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA00365; Tue, 11 Apr 89 08:13:59 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 11 Apr 89 11:07
To: quinquevirate@sail.stanford.edu
Subject: checked-out sections
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2 Moon 4/11/89
3.1 Masinter 4/11/89
3.2 Masinter 4/11/89
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
∂11-Apr-89 0852 Quinquevirate-mailer
To: quinquevirate@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.SYMBOLICS.COM
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Glossary
KMP writes:
`` - I feel funny about the use of the word ``contains'' in ``generic
function.'' ''
The reason to use it is that some people have the idea that a
generic function is really just a name and that there are
a set of methods that are associated with that name. A test of this
misconception is to see how they react when you say you want to
save the old definition of a generic function G by grabbing #'G,
dork around with a new definition of G, and then restore the old one.
That is, the word ``contain'' is intended to make you think that when
you pick up a generic function object, the methods ``come along too.''
The word ``contain'' probably implies slightly too much about implementation,
but a generic function acts as if the methods and the method combination were
part of it.
KMP, would you feel that some phrasing that said that a generic function
was simply a function and could be used exactly the same way would preclude
people from thinking generic functions were amorphous?
Also, note that the current glossary definition is pretty much excerpted from
88-002R.
-rpg-
∂11-Apr-89 0903 Quinquevirate-mailer Progress
To: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I have the history section checked out. What I'm trying to do with it
is to outline briefly what the various roots of CL contributed, and
to give an idea of the family tree of Lisp. I hope that I use
about the same space. I'm 1/2 done with this rewrite.
As I mentioned to KC earlier, my schedule until April 26 is pretty
bad (180 OOPSLA papers to read). After that, I plan to devote almost
all of my time to the draft. I think Steele's schedule has a similar
shape.
-rpg-
∂11-Apr-89 0911 Quinquevirate-mailer glossary description of `generic function'
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89 09:11:02 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 575190; 11 Apr 89 12:11:01 EDT
Date: Tue, 11 Apr 89 12:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: glossary description of `generic function'
To: RPG@SAIL.Stanford.EDU
cc: quinquevirate@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <UMWcZ@SAIL.Stanford.EDU>
Message-ID: <890411121004.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
I see your point, and I agree with your concern. Part of my problem,
perhaps, was the harsh and unmotivated transition from a generic
function as a function to a generic function as a container. How
about something like...
generic function - a <function> whose behavior depends on the <classes>
or <identities> of the arguments supplied to it. Unlike an ordinary
<function>, a <generic function> can also be viewed as an <object> with
state that can be examined and modified without actually invoking the
functional component. This state includes, among other things, a set
of <methods>, a <lambda list>, and a method combination type.
∂11-Apr-89 0927 Quinquevirate-mailer Glossary
To: quinquevirate@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.SYMBOLICS.COM
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Hm, how about this:
generic function - a <function> whose behavior depends on the <classes>
or <identities> of the arguments supplied to it. Unlike an ordinary
<function>, a <generic function> is also an <object> whose parts include,
among other things, a set of <methods>, a <lambda list>, and a method
combination type.
∂11-Apr-89 0930 Quinquevirate-mailer Glossary
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89 09:30:26 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 575205; Tue 11-Apr-89 12:30:26 EDT
Date: Tue, 11 Apr 89 12:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Glossary
To: RPG@SAIL.Stanford.EDU
cc: quinquevirate@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <UMXDp@SAIL.Stanford.EDU>
Message-ID: <890411122944.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 11 Apr 89 0927 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Hm, how about this:
generic function - a <function> whose behavior depends on the <classes>
or <identities> of the arguments supplied to it. Unlike an ordinary
<function>, a <generic function> is also an <object> whose parts include,
among other things, a set of <methods>, a <lambda list>, and a method
combination type.
Fine.
∂12-Apr-89 1449 Quinquevirate-mailer checked out (4/12)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Apr 89 14:49:21 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA22640; Wed, 12 Apr 89 14:49:51 PDT
Message-Id: <8904122149.AA22640@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA22640; Wed, 12 Apr 89 14:49:51 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 12 Apr 89 17:46
To: quinquevirate@sail.stanford.edu
Subject: checked out (4/12)
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2 Moon 4/11/89
3.1 Masinter 4/11/89
3.2 Masinter 4/11/89
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 4/12/89
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
!
From: DECWRL::AITG::CHAPMAN "11-Apr-89 1107 GMT" 11-APR-1989 11:18:16.25
To: quinquevirate@sail.stanford.edu
CC:
Subj: checked-out sections
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2 Moon 4/11/89
3.1 Masinter 4/11/89
3.2 Masinter 4/11/89
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
∂13-Apr-89 0226 Quinquevirate-mailer I'd like to send this to X3J13
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Apr 89 02:26:38 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA29997; Thu, 13 Apr 89 02:27:20 PDT
Message-Id: <8904130927.AA29997@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA29997; Thu, 13 Apr 89 02:27:20 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 13 Apr 89 05:24
To: quinquevirate@sail.stanford.edu
Subject: I'd like to send this to X3J13
Since a letter ballot date is approaching, I'd like to send the following
to X3J13 to clarify what has happened with those dates. Do you approve
of sending the following?
kc
The formation of the drafting committee causes scheduled voting dates
on parts of the standard to change. Therefore, if you are planning to
review the document on the schedule set up by the issue CUT-OFF-DATES,
please revise your plan taking the following into account.
From now on the drafting committee will review or rewrite
as necessary according to the following schedule:
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application 6/14/89
1.2 Organization of the Document Done
1.3 Referenced Publications Done
1.4 Definitions Done
1.5 Compliance 5/1/89
1.6 Language Extensions 5/1/89
Chapter 2. Objects and Types
CONTENTS
2.1 Introduction Done
2.2 Types 5/1/89
2.3 Classes Done
2.4 Slots Done
2.5 Objects Done
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader 5/1/89
3.2 Object Syntax 5/1/89
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model 5/14/89
4.2 Compilation 6/14/89
Chapter 5. Other Topics
CONTENTS
5.1 Errors 5/14/89
5.2 Input/Output 5/1/89
5.3 Interface with the Programming Environment 5/1/89
5.4 Generalized Reference 5/1/89
Chapters 6 and 7. Catalog of Defined Names
CONTENTS
6.1 Introduction 5/1/89
The following list contains the names of groups of functions as they
appear in CLtL, CLOS, and the Condition System documents. For example,
the functions in Chapter 15 (Lists) of CLtL are to be reviewed and/or
rewritten by 5/1/89.
CLOS 5/1/89
PREDICATES 5/1/89
STRINGS 5/1/89
SEQUENCES 5/1/89
LISTS 5/1/89
NUMBERS 5/1/89
STRUCTURES 5/14/89
SYMBOLS 5/14/89
HASH-TABLES 5/14/89
ARRAYS 5/14/89
TYPES 5/14/89
DECLARATIONS 5/14/89
IO 6/14/89
STREAMS 6/14/89
FILE 6/14/89
CONTROL 6/14/89
PROGRAM 6/14/89
MISC 6/14/89
ERRORS 6/14/89
MACROS 6/14/89
PACKAGES 6/14/89
CHARACTERS 6/14/89
EVALUATOR 6/14/89
Glossary 5/1/89
These dates are goals, not fixed deadlines. However, if you would
like to comment on a section before the reviewer/rewriter works on
it, you should get your comments to me before the date listed for
the section.
When a section is ready for ballot it will be mailed for vote.
The goal is to complete all sections by the June meeting. Coming to closure
on all the sections by the June meeting is not a goal; having all the sections
ready for review by X3J13 between June and September IS a goal.
So if you only have time for one review, you should plan to review after
the drafting committee has completed its work, i.e. around mid- to late-July.
As usual, if you need hardcopies, please don't hesitate to ask. The files
on hudson.dec.com are updated once per week, usually on Tuesday night or
Wednesday morning. If you have trouble accessing them, please let me know
ASAP. If you forgot how to access them, please let me know. Please note that
ALL reviews and comments are APPRECIATED. In most cases, and always when the
comments are on a recently-published version or are extensive, you will receive
replies to your comments.
Thanks again for your help.
the drafting committee
∂13-Apr-89 1037 Quinquevirate-mailer I'd like to send this to X3J13
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Apr 89 10:37:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 576737; Thu 13-Apr-89 13:36:22 EDT
Date: Thu, 13 Apr 89 13:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: I'd like to send this to X3J13
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8904130927.AA29997@decwrl.dec.com>
Message-ID: <19890413173617.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 13 Apr 89 05:24
From: chapman%aitg.DEC@decwrl.dec.com
Since a letter ballot date is approaching, I'd like to send the following
to X3J13 to clarify what has happened with those dates. Do you approve
of sending the following?
It's fine by me. I'm not real good on dates and schedules, so I can't
claim to have carefully checked that the schedule is doable.
The formation of the drafting committee causes scheduled voting dates
on parts of the standard to change. Therefore,....
∂14-Apr-89 0511 Quinquevirate-mailer checked-out (4/13)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Apr 89 05:11:28 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05792; Fri, 14 Apr 89 05:12:12 PDT
Message-Id: <8904141212.AA05792@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA05792; Fri, 14 Apr 89 05:12:12 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 14 Apr 89 08:07
To: quinquevirate@sail.stanford.edu
Subject: checked-out (4/13)
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2 Moon 4/11/89
3.1 Masinter
3.2 Masinter
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 4/12/89
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
∂16-Apr-89 2229 Quinquevirate-mailer History Section (1.1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Apr 89 22:29:46 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA08169g; Sun, 16 Apr 89 22:29:50 PDT
Received: by challenger id AA00492g; Sun, 16 Apr 89 22:29:39 PDT
Date: Sun, 16 Apr 89 22:29:39 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904170529.AA00492@challenger>
To: quinquevirate@sail.stanford.edu
Subject: History Section (1.1)
Here is my current rewrite of the history section (1.1). It is a
little more, but slightly more complete while being quite terse (what
it lacks in verbosity it makes up for in terseness). This version is
the result of comments by Masinter and Bobrow, so some of it is
probably accurate. Jonl says he cannot review it for a few months, so
I'll leave it to Steele and Moon to review the Maclisp and Zetalisp
stuff.
%%Scope, Purpose, and History
\beginsubSection{Scope and Purpose}
The specification set forth in this document is designed to promote
the portability of @clisp\ programs among a variety of data-processing
systems. It is a language specification aimed at an audience of
implementors and knowledgeable programmers: It is neither a tutorial nor
an implementation guide.
\endsubSection%{Scope and Purpose}
\beginsubSection{History}
Lisp is a family of languages with a long history. Early key ideas in
Lisp were developed by John McCarthy during the 1956 Dartmouth Summer
Research Project on Artificial Intelligence. McCarthy's motivation
was to develop an algebraic list processing language for artificial
intelligence work.
In 1957, on McCarthy's advice, Herbert Gelernter and Carl Gerberich
implemented a list processing language within FORTRAN, called
FLPL---FORTRAN List Processing Language. This was a set of subroutines
that were added to FORTRAN on the IBM~704 computer. Under the
direction of McCarthy, the first real Lisp---Lisp~1---was implemented
for the IBM~704 computer in 1958. Lisp~1.5 was an extension of
Lisp~1. It was implemented on the IBM~7090 computer at MIT. A later
version of Lisp~1.5 on the PDP-6 was the ancestor of MacLisp.
MacLisp improved on the Lisp~1.5 notion of special variables and error
handling. MacLisp also introduced into Lisp functions that could take
a variable number of arguments, macros, arrays, non-local dynamic
exits, fast arithmetic, the first good Lisp compiler, and an emphasis
on execution speed.
In 1963 L. Peter Deutsch, then a high school student, implemented
Basic PDP-1 Lisp, a Lisp similar to Lisp~1.5, at MIT. At Bolt,
Beranek, \& Newman, BBN Lisp was implemented on the PDP-10 by Daniel
Bobrow, D. L. Murphy, and Alice Hartley. In 1972, the maintenance of
BBN~Lisp---its name changed to InterLisp---was shared by BBN and Xerox
Palo Alto Research Center.
InterLisp introduced many ideas into Lisp programming environments,
style, and methodology. One of them was an iteration construct
implemented by Warren Teitelman which inspired the LOOP construct used
both on the Lisp Machines and in MacLisp, and now in @clisp.
Although the first implementations of Lisp were on the IBM~704 and the
IBM~7090, later work focussed on the Digital Equipment Corporation
PDP-10 computer, which was the mainstay of Lisp and artificial
intelligence work at MIT, Stanford, BBN, and CMU from the mid-1960's
through much of the 1970's.
The PDP-10 computer and its predecessor the PDP-6 computer were, by
design, especially well-suited to Lisp because they had 36-bit words
and 18-bit addresses. This architecture allowed a CONS cell to be
stored in one word; single instructions extracted the CAR and CDR
parts. The PDP-6 and PDP-10 had fast, powerful stack instructions
that enabled fast function calling.
But the limitations of the PDP-10 were evident by 1973: it supported a
small number of researchers using Lisp, and the small, 18-bit address
space ($2↑{18}$ $=$ 262,144 words) limited the size of a single
program.
One response to the address space problem was the Lisp machine, a
special-purpose computer designed to run Lisp programs. The other
response was to use computers with address spaces larger than 18~bits,
such as the Digital Equipment Corporation Vax and the S-1~Mark~IIA.
The Lisp machine concept was developed in the late 1960's. In the
early 1970's, Deutsch, working with Bobrow, implemented a Lisp on the
Alto, a single-user minicomputer, using microcode to interpret a
byte-code implementation language. At approximately the same time,
Richard Greenblatt began work on a different hardware and
instruction-set design at MIT.
Eventually, a dialect of Interlisp known as Interlisp-D became
available on the D-series machines manufactured by Xerox---the Dorado,
Dolphin, and later the Dandelion. An upward-compatible extension of
MacLisp called ZetaLisp became available on the early MIT Lisp
machines. Commercial Lisp machines from Xerox, Lisp Machines, Inc.
(LMI), and Symbolics, Inc., were on the market by 1981.
During the mid-1970's, ZetaLisp began to expand towards a much fuller
language. Sophisticated lambda-lists, SETF, multiple values,
packages, and structures like those in @clisp\ are the results of
early experimentation with programming styles by the Lisp machine
group; these styles found their way into MacLisp.
Around 1980, Scott Fahlman and others at CMU began work on a Lisp to
run on the SPICE (Scientific Personal Integrated Computing
Environment) workstation. One of the goals of the project was to
design a simpler dialect than ZetaLisp.
The Macsyma group at MIT began a project during the late 1970's called
the New Implementation of Lisp (NIL) for the Vax. One of the stated
goals of the NIL project was to fix many of the historic, but
annoying, problems with Lisp while retaining compatibility with
MacLisp. About the same time, a research group at Stanford University
and Lawrence Livermore National Laboratory began the design of a Lisp
to run on the S-1~Mark~IIA supercomputer. S-1~Lisp, never completely
functional, was the test bed for adapting advanced compiler techniques
to Lisp implementation. Eventually the S-1 and NIL groups
collaborated.
The first efforts towards Lisp standardization were Standard Lisp and
Portable Standard Lisp (PSL). In 1969, Anthony Hearn and Martin Griss
defined Standard Lisp as a subset of Lisp~1.5 and other dialects to
transport REDUCE, a symbolic algebra system. Portable Standard Lisp
(PSL) was designed tp provide more control over the environment and
the compiler.
At the end of the 1970's, PSL ran on about a dozen different
computers. PSL and Franz Lisp---a MacLisp-like dialect for Unix
machines---were the first examples of widely available Lisp dialects
on multiple hardware platforms.
One of the most important developments in Lisp occurred during the
second half of the 1970's: Scheme. Scheme, designed by Gerald J.
Sussman and Guy L. Steele Jr., is a simple dialect of Lisp whose
design brought to Lisp some of the ideas from programming language
semantics developed in the 1960's. Sussman was one of the prime
innovators behind many other advances in Lisp technology from the late
1960's through the 1970's.
The major contributions of Scheme were lexical scoping, first-class
functions and continuations, and simplified syntax (no separation of
values and functions). Some of these contributions made a large impact
on the design of @clisp.
In the mid-1970's object-oriented programming concepts started to make
a strong impact on Lisp' At MIT, Flavors, an object-oriented
programming system with multiple inheritance patterned after
Smalltalk was developed and integrated into Lisp machines. At Xerox,
the experience with Smalltalk and KRL led to the development of LOOPS.
These systems influenced the design of the Common Lisp Object System
(CLOS).
In 1980 Symbolics and LMI were developing ZetaLisp; stock-hardware
implementation groups were developing NIL, Franz Lisp, and PSL; Xerox
was developing InterLisp; and the SPICE project at CMU was developing
a MacLisp-like dialect of Lisp called SpiceLisp.
In April 1981, after a DARPA-sponsored meeting concerning the
splintered Lisp community, Symbolics, the SPICE project, the NIL
project, and the S-1~Lisp project joined together to define @clisp.
This effort was led by Scott Fahlman, Daniel Weinreb, David Moon, Guy
L. Steele Jr., and Richard Gabriel. @clisp\ was designed as a
description of a family of languages. The primary influences on
@clisp\ were ZetaLisp, MacLisp, NIL, S-1~Lisp, Spice Lisp, and Scheme.
{\it Common Lisp the Language\/} is a description of that design. Its
semantics were intentionally underspecified in places where it was
felt that a tight specification would overly constrain @clisp\
research and use. However, industrial use of @clisp\ mandates
stricter standardization for portability. Left out of the original
@clisp\ were an object-oriented programming system, a condition
system, iteration facilities, and a way to handle large character
sets. Therefore, a new language specification, this document, was
developed by the X3J13 committee.
\endsubSection%{History}
∂18-Apr-89 2137 Quinquevirate-mailer issues that will probably pass in June?
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Apr 89 21:37:00 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA04753; Tue, 18 Apr 89 10:48:41 PDT
Message-Id: <8904181748.AA04753@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA04753; Tue, 18 Apr 89 10:48:41 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 Apr 89 13:44
To: quinquevirate@sail.stanford.edu
Subject: issues that will probably pass in June?
This is the list I promised. At Larry's suggestion, I will try to include
hooks for these issues, though not exact wording, in the standard before
the June meeting. Any suggestions for additions or deletions?
kc
*****************************************************************************
Issues that will probably come up and pass in some form in June:
*****************************************************************************
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE 433
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
Issue: DYNAMIC-EXTENT-FUNCTION
Edit history: 04-Apr-89, Version 1 by Loosemore
Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
Edit history: 06-Mar-89, Version 1 by Pitman
Issue: HASH-TABLE-SIZE
Edit history: Version 1, 20-Mar-89, by Moon
Issue: LOAD-TRUENAME
11-Apr-89, Version 4 by Pitman (merge Moon's v3 comments)
Issue: PATHNAME-COMPONENT-CASE
22-Mar-89, Version 2 by Moon, update and rewrite
Issue: PATHNAME-COMPONENT-VALUE
Edit history: Version 1, 20-Mar-89, by Moon
Issue: PATHNAME-SUBDIRECTORY-LIST 463
23-Mar-89, Version 4 by Pitman ([hopefully] just fix typos)
Issue: PATHNAME-SYNTAX-ERROR-TIME
Edit history: 07-Jul-88, Version 1 by Pitman
Issue: PATHNAME-WILD
06-Oct-88, Version 2 by Pitman
Issue: PRETTY-PRINT-INTERFACE
Version 4, 22-Mar-89 by Waters
Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
Edit history: 26-Jan-89, Version 1 by Pitman
Issue: READ-CASE-SENSITIVITY
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Issue: CLOS-MACRO-COMPILATION 454
V3, 21 Mar 1989, Sandra Loosemore (fix error language)
Issue: COMPILE-ENVIRONMENT-CONSISTENCY 312 418
V5, 22 Mar 1989, Sandra Loosemore (fix error language)
Issue: COMPILE-FILE-SYMBOL-HANDLING 455
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
Issue: COMPILED-FUNCTION-REQUIREMENTS 443
V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
Issue: CONSTANT-FUNCTION-COMPILATION
Edit History: V1, 22 Mar 1989, Sandra Loosemore (split from issue
CONSTANT-COMPILABLE-TYPES)
Issue: DEFCONSTANT-NOT-WIRED 457
13 Mar 1989, V6 by Sandra Loosemore (start over)
Issue: MACRO-CACHING 449
11-Mar-89, Version 2 by Loosemore (add discussion)
Issue: PROCLAIM-ETC-IN-COMPILE-FILE 318
13 Mar 89, V4 by Sandra Loosemore (discussion)
Issue: SYNTACTIC-ENVIRONMENT-ACCESS 461
Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
Issue: CONFORMANCE-POSITION
Issue: EXTRA-RETURN-VALUES
∂19-Apr-89 0707 Quinquevirate-mailer History Section (1.1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 07:07:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 580757; Tue 18-Apr-89 17:48:19 EDT
Date: Tue, 18 Apr 89 17:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: History Section (1.1)
To: quinquevirate@sail.stanford.edu
In-Reply-To: <8904170529.AA00492@challenger>
Message-ID: <19890418214816.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 16 Apr 89 22:29:39 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Here is my current rewrite of the history section (1.1).
This is mostly good. It's so terse that it reads rather choppily, but
since that's intentional, I won't complain.
I have a few comments (all nit picking I think):
One response to the address space problem was the Lisp machine, a
special-purpose computer designed to run Lisp programs. The other
response was to use computers with address spaces larger than 18~bits,
such as the Digital Equipment Corporation Vax and the S-1~Mark~IIA.
I think the word "general-purpose" is missing from the third line. The
Lisp machine is also a computer with address space larger than 18 bits.
"Lisp Machine" is usually spelled with both words capitalized.
"VAX" is usually spelled in all caps.
I'm obliged to point out that the word "ZetaLisp" is a registered
trademark of Symbolics, Inc., so this shouldn't say that other
organizations (such as LMI and MIT) were also developing something
called "ZetaLisp". I don't remember what it was called at MIT,
perhaps just "Lisp Machine Lisp."
During the mid-1970's, ZetaLisp began to expand towards a much fuller
ZetaLisp didn't exist until 1980 or 1981, and Lisp Machine Lisp began
to expand in 1976 or 1977, so I would say the late 1970's rather than
the mid 1970's.
In the mid-1970's object-oriented programming concepts started to make
a strong impact on Lisp' At MIT, Flavors, an object-oriented
programming system with multiple inheritance patterned after
Smalltalk was developed and integrated into Lisp machines. At Xerox,
Maybe this is late 1970's too, I'm not sure. More to the point, I'd
change the word order since the multiple inheritance as the part that
was -not- patterned after Smalltalk:
At MIT, Flavors, an object-oriented programming system patterned
after Smalltalk but with multiple inheritance, was developed and
integrated into Lisp Machines.
I agree with this paragraph but there is something wrong with the way
the 3rd sentence flows into the 4th sentence. I haven't been able to
figure out quite how to rework it, but the outline is:
CLtL had this goal
The new language has a different goal
These are the differences
Maybe someone else can take a stab at it.
{\it Common Lisp the Language\/} is a description of that design. Its
semantics were intentionally underspecified in places where it was
felt that a tight specification would overly constrain @clisp\
research and use. However, industrial use of @clisp\ mandates
stricter standardization for portability. Left out of the original
@clisp\ were an object-oriented programming system, a condition
system, iteration facilities, and a way to handle large character
sets. Therefore, a new language specification, this document, was
developed by the X3J13 committee.
∂19-Apr-89 0849 Quinquevirate-mailer History Section (1.1)
To: Quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Thanks, Dave, for your comments. When I stop reading OOPSLA papers
(next week) I will get back in the saddle. Two questions for the
whole group, assuming accuracy is acceptable at some point:
1. Is the section too terse and if so how much real estate
are we willing to spend on this section? The same facts
that you now see were distilled from a section 50% longer
than what you're reading. That might have been to steep
a shrinkage.
2. Do we want such a section at all? Is there a precedent?
3. Should we simply start at the April 1981 date and talk only
about the Common Lisp process?
About OOPSLA, I would guess that the worst 5 papers submitted to the
last L&FP would be in the 50% percentile of the papers submitted to OOPSLA.
-rpg-
∂20-Apr-89 0900 Quinquevirate-mailer Sections 2.3 and 2.5
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89 09:00:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 581860; Thu 20-Apr-89 12:00:01 EDT
Date: Thu, 20 Apr 89 12:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sections 2.3 and 2.5
To: quinquevirate@sail.stanford.edu
Message-ID: <19890420160017.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Sections 2.3 and 2.5 are marked as done, but here are some comments
from one of our CLOS implementors, who has just done a very careful
reading of the 5.10 versions of 2.3, 2.4, and 2.5. This message is
mainly to KC, but I thought all the qinquevirate should be copied.
RPG in particular might have comments.
I [still Moon] think these comments fall into two categories. One is
editorial problems introduced by reorganizing the text that was in
88-002R and those are straightforward to handle. The other is problems
with the Common Lisp language caused by the metaobjects portion of CLOS
not getting done on time. Right now we have some small inconsistencies
in the language due to this. Possible approaches would be to
exterminate anything that mentions metaobjects, or to incorporate some
selected portions of the beginning of chapter 3 into the standard, or to
flag some portions of the specification as being a framework for future
extensions that shouldn't be expected to make sense standing on its own
without those extensions. I currently favor the third course, partly
because I think it is the easiest. The comments below may not completely
flag all the places where this should be done; if the drafting committee
decides this is the right course of action, I (or Dick?) can go through
and flag all such places.
p.2-3, para.3: Without meta objects one can't create anonymous classes
and improper class names, so much of this paragraph is currently
irrelevant. Keep the first two sentences and the last sentence, delete
the rest. [I think we should keep it anyway, but flag it as a framework
for future extensions --Moon]
p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
the current metaobject-free standard.
p.2-5, bullet 3: changing "is shared by instances" to
"is shared by all instances" would be clearer.
p.2-5: Delete the 3-line inheritance section. This section has been
reorganized into nonexistence.
p.2-5: Inheritance of Class Options should come after the class
precedence list section.
p.2-9, Redefining Classes, Third paragraph: The CLOS spec says when
slots aren't updated, X3J13 says when they are updated. X3J13 doesn't
mention anything about changes to ordering. [How come this spec.
doesn't say exactly the same thing as 88-002R here? --Moon]
In several of these paragraphs, references are made to the "old class"
and the "new class". It would be clearer to say "the old class
definition" and "the new class definition" since it's still the same
class object after the redefinition.
p.2-24: If there's no MOP, then "These procedures can be customized ..."
should go away, as well as the last sentence of the next paragraph.
p.2-26: It would be nice if it said "Every generic function is an
instance of the class standard-generic-function or one of its
subclasses". [But I don't think that's true, at least after
metaobjects are put in. --Moon]
∂22-Apr-89 1136 Quinquevirate-mailer Sections 2.3 and 2.5
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Apr 89 11:36:39 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA15597g; Sat, 22 Apr 89 11:36:36 PDT
Received: by challenger id AA01737g; Sat, 22 Apr 89 11:36:27 PDT
Date: Sat, 22 Apr 89 11:36:27 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904221836.AA01737@challenger>
To: quinquevirate@sail.stanford.edu
Subject: Sections 2.3 and 2.5
Of the three approaches Moon suggests, I favor a combination of
bringing some stuff into the main specification from the prototype
chapter 3 and flagging the rest as places for future extension.
I feel that the largest exposures we have are readers (but not
writers) for some things like these (this list suggested by Jonl):
class-direct-supers, class-direct-subclasses, class-direct-slots,
class-slots, class-direct-methods, class-precedence-list,
class-forward-referenced-supers, class-no-of-instance-slots,
method-function, method-generic-function, method-arglist,
method-qualifiers, method-specializers, generic-function-name,
generic-function-methods, generic-function-discriminator-code,
generic-function-lambda-list, slotd-name, slotd-allocation,
slotd-initform, slotd-initargs, and slotd-type.
Also we are exposed on the inability to make methods for add-method to
use. These are the places where I would consider trying move something
into the main specification.
Someone writes:
``p.2-3, para.3: Without meta objects one can't create anonymous
classes and improper class names, so much of this paragraph is
currently irrelevant. Keep the first two sentences and the last
sentence, delete the rest. [I think we should keep it anyway, but
flag it as a framework for future extensions --Moon]''
Hm, I thought CLASS-NAME was a SETFable place, as was FIND-CLASS, but
I guess that isn't true as it currently stands.
``p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
the current metaobject-free standard.''
Well, there are various metaclasses now (structure-class and
standard-class), and there are some places that talk about compatible
metaclasses. I can't believe it's reasonable to flush all mention of
metaclasses because you cannot create them. (Actually, you can, but it
isn't likely that you can do anything useful with them. For example,
you can do (defclass random-metaclass (standard-class)) and then
proceed to make instances of it which are hardly distinguishable from
ordinary standard classes.)
``p.2-5, bullet 3: changing "is shared by instances" to
"is shared by all instances" would be clearer.''
This is fine. Kathy, can you do this?
``p.2-5: Delete the 3-line inheritance section. This section has been
reorganized into nonexistence.
p.2-5: Inheritance of Class Options should come after the class
precedence list section.''
Ok. Kathy, can you do this?
``p.2-9, Redefining Classes, Third paragraph: The CLOS spec says when
slots aren't updated, X3J13 says when they are updated. X3J13 doesn't
mention anything about changes to ordering. [How come this spec.
doesn't say exactly the same thing as 88-002R here? --Moon]''
I don't quite get this. I have the Feb 14 X3J13 draft here (my March 21
draft is at work), and both the Feb 14 draft and 88-002R say this:
``Note that redefining a class may cause slots to be added or deleted.
If a class is redefined in a way that changes the set of local slots
accessible in instances, the instances will be updated. It is
implementation dependent whether instances are updated if a class is
redefined in a way that does not change the set of local slots
accessible in instances.''
On the other hand, this paragraph appears on page 2-47 not 2-9, so it's
hard to tell whether we are all talking about the same thing.
``In several of these paragraphs, references are made to the "old class"
and the "new class". It would be clearer to say "the old class
definition" and "the new class definition" since it's still the same
class object after the redefinition.''
I think there is ample distinction made in the first paragraph of this section
between the class object and the class. This section and others like it
are difficult enough to understand without extra words like ``definition''
being thrown in where that doesn't really aid understanding. Consider how
you would rewrite this using ``definition'':
``The value of a slot that is specified as shared both in the old class
and in the new class is retained. If such a shared slot was unbound
in the old class, it will be unbound in the new class. Slots that
were local in the old class and that are shared in the new class are
initialized. Newly added shared slots are initialized.''
Here is a try:
``The value of a slot that is specified as shared both by the old
class definition and by the new class definition is retained. If such
a shared slot was unbound in the class specified by the old
definition, it will be unbound in the class specified by the new
definition. Slots that were specified as local by the old class
definition and that are specified as shared by the new class are
initialized. Newly added shared slots are initialized.''
I'm not sure that this slightly more precise paragraph says anything
more than the original, and it is a lot harder to understand.
Finally, the classes might be EQ, but they are not equal as classes.
(1 2 3) and (a b c d e) might be EQ, but one is the old list and the
other is the new list, if one was derived from the other via
replacement.
-rpg-
∂23-Apr-89 2053 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Apr 89 20:53:19 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA16143g; Sun, 23 Apr 89 20:52:37 PDT
Received: by challenger id AA02650g; Sun, 23 Apr 89 20:52:30 PDT
Date: Sun, 23 Apr 89 20:52:30 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904240352.AA02650@challenger>
To: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
Subject: Function constants
I haven't followed the discussion on constants, so this might
repeat some material.
The first question is what it means to be a function constant. It
doesn't mean a constant function, which is a function that returns the
same thing every time it's called. But, does it mean that it has
an alterable environment?
(let ((a (list 1 2 3)))
(labels ((f (x n) (+ x (nth n a)))
(g (x n) (setf (nth n a) x)))
...))
Is G suitable as a function constant? How about F? I happen to think
both are suitable as function constants, and the intuitive behavior
should be enforced. The reason is that there is no structural
modification that is being done to the functions to alter them.
That it, there is nothing like
(setf (<some-part-of> F) <new-value>)
that is taking place, just the normal function invocation.
The second question is how do you dump such a thing as a function.
Well, if your compiler can compile-file this you are part way there:
(defun f (x y) (+ x y))
That is, you can dump and load functions.
The objection might be that a non-null environment is needed. If you
cannot compile-file this then you are out of conformance anyway:
(let ((a (list 1 2 3)))
(defun (x n) (+ x (nth n a)))
(defun g (x n) (setf (nth n a) x)))
So the remaining problem is how to dump ``code vectors.'' This is
simple if you have position-independent code, because then you just
dump the bits as if it were a bit-vector. The question is whether we
wish to support machines that have no such thing as position
independent code or do we wish to require implementations to keep
relocation information around (which they will anyway if they can
garbage collect code and compact the space). [Note that the
environments have to be put in something other than a readonly space,
one that the GC sees.]
There are possibly some other problems, such as the material that
might appear as additional information in something like a procedure
header. For example, links to other functions or weird system- or
machine-dependent information. I think we have to assume (and make it
absolutely clear) that we can only specify compilation when the
compiled code is being loaded into a Common Lisp that is identical to
the one doing the compiling (See the next paragraph.)
An alternative to the function constant problem is as follows: We
state that compilation is meaningful in only two situations: COMPILE
in an image with no dumping allowed and COMPILE-FILE in a fresh Lisp
where the compilation will not load any compiled code, where only one
compilation unit will be compiled, and where the result will be loaded
in a copy of the same fresh Lisp that was used to do the compilation.
Calls to COMPILE are allowed in the second scenario. (That is, you
start a lisp, compile-file, quit, start afresh that same Lisp, load.)
In these two cases we can allow the free use of functions as constants
because either there is no need to dump stuff, or else all the source
code that is needed can be made available. That is, in this case, all
the functions that could be constants have either had their source
examined and saved by the very compiler doing all the work or else are
functions in the Common Lisp package, which can be dumped by name.
This case is a little restrictive, but this would be a conservative
case for which we are able to specify the meaning of compilation. Some
implementations might be able to handle less restrictive cases, but it
isn't required.
-rpg-
∂24-Apr-89 0640 Quinquevirate-mailer Re: Function constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Apr 89 06:39:42 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18845; Mon, 24 Apr 89 07:39:48 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10255; Mon, 24 Apr 89 07:39:45 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904241339.AA10255@defun.utah.edu>
Date: Mon, 24 Apr 89 07:39:43 MDT
Subject: Re: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
Cc: cl-compiler@sail.stanford.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Sun, 23 Apr 89 20:52:30 PDT
[CC'ed to cl-compiler.]
> Date: Sun, 23 Apr 89 20:52:30 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
>
> The first question is what it means to be a function constant. It
> doesn't mean a constant function, which is a function that returns the
> same thing every time it's called. But, does it mean that it has
> an alterable environment?
I would define a function constant as an object of type FUNCTION that
appears as a quoted or self-evaluating form. (This is quite distinct
from a FUNCTION special form.)
> The second question is how do you dump such a thing as a function.
> Well, if your compiler can compile-file this you are part way there:
>
> (defun f (x y) (+ x y))
>
> That is, you can dump and load functions.
No, this is a FUNCTION special form, not a function constant. What
you are dumping and loading is code which will create a function
object when executed, not the function object itself.
> So the remaining problem is how to dump ``code vectors.'' This is
> simple if you have position-independent code, because then you just
> dump the bits as if it were a bit-vector. The question is whether we
> wish to support machines that have no such thing as position
> independent code or do we wish to require implementations to keep
> relocation information around (which they will anyway if they can
> garbage collect code and compact the space). [Note that the
> environments have to be put in something other than a readonly space,
> one that the GC sees.]
I agree this is the main question from an implementation point of
view. I know that for some implementations (i.e., UCL), this
requirement would be a major headache.
I'd argue that since this isn't compatible with current practice, and
is a lot of work to implement, that it probably isn't a good thing to
require unless doing so would provide some desperately needed
functionality that is now missing from the language. I question
whether the need for the ability to dump function constants is really
all that great. I'm having a hard time even coming up with a
realistic example that could not also be handled using
LOAD-TIME-VALUE.
There is also a problem with dumping closures that you didn't mention.
Unless the object is looked up "by name" by the loader, the dump/load
process inherently creates a copy of the original object. Closure
environments are no exception to that rule, which could lead to some
unexpected behavior.
> An alternative to the function constant problem is as follows: We
> state that compilation is meaningful in only two situations: COMPILE
> in an image with no dumping allowed and COMPILE-FILE in a fresh Lisp
> where the compilation will not load any compiled code, where only one
> compilation unit will be compiled, and where the result will be loaded
> in a copy of the same fresh Lisp that was used to do the compilation.
> Calls to COMPILE are allowed in the second scenario. (That is, you
> start a lisp, compile-file, quit, start afresh that same Lisp, load.)
>
> In these two cases we can allow the free use of functions as constants
> because either there is no need to dump stuff, or else all the source
> code that is needed can be made available. That is, in this case, all
> the functions that could be constants have either had their source
> examined and saved by the very compiler doing all the work or else are
> functions in the Common Lisp package, which can be dumped by name.
We've already said that it's OK for function constants to appear in
code processed by COMPILE or EVAL -- issue QUOTE-SEMANTICS said that
constraints on what kinds of objects can appear in constants apply
only to COMPILE-FILE, and that COMPILE never copies.
I'd accept a statement that your second case is the only situation in
which function constants seen by COMPILE-FILE make sense, but saying
that's the only situation in which compilation with COMPILE-FILE is
meaningful seems like it's going way too far in the wrong direction.
Random people picking up the Common Lisp standard would get a very bad
impression of the language from seeing a restriction like that, and
it's certainly not consistent with current practice.
-Sandra
-------
∂24-Apr-89 1424 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Apr 89 14:24:47 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00240g; Mon, 24 Apr 89 09:20:34 PDT
Received: by challenger id AA03231g; Mon, 24 Apr 89 09:18:58 PDT
Date: Mon, 24 Apr 89 09:18:58 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904241618.AA03231@challenger>
To: sandra%defun@cs.utah.edu
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 24 Apr 89 07:39:43 MDT <8904241339.AA10255@defun.utah.edu>
Subject: Function constants
``No, this is a FUNCTION special form, not a function constant. What
you are dumping and loading is code which will create a function
object when executed, not the function object itself.''
I know, but if you cannot dump anything like a function in any context,
you're really losing. (I don't believe in smiley faces, but there should
have been one there.)
``I agree this is the main question from an implementation point of
view. I know that for some implementations (i.e., UCL), this
requirement would be a major headache.''
I'll challenge this. I think only KCL might not be able to do it.
Is UCL Utah Common Lisp?
``I'd argue that since this isn't compatible with current practice....''
If no one can do it because it is too hard to implement, how can it be
incompatible? You mean that it isn't part of current practice.
``I question whether the need for the ability to dump function
constants is really all that great. I'm having a hard time even
coming up with a realistic example that could not also be handled
using LOAD-TIME-VALUE''
This is an interesting point. I actually almost never use constants
of any sort except for NIL and numbers. Maybe someone could make a
little list of the uses of constants aside from numbers and lists -
maybe having anything but those around is worthless.
``We've already said that it's OK for function constants to appear in
code processed by COMPILE or EVAL -- issue QUOTE-SEMANTICS said that
constraints on what kinds of objects can appear in constants apply
only to COMPILE-FILE, and that COMPILE never copies.''
``I'd accept a statement that your second case is the only situation in
which function constants seen by COMPILE-FILE make sense, but saying
that's the only situation in which compilation with COMPILE-FILE is
meaningful seems like it's going way too far in the wrong direction.''
Well, here's an interesting point. I think it is important for our
specification of compiler semantics to be the same regardless of the
context - otherwise we are specifying too many languages. Already we
see arguements that COMPILE and COMPILE-FILE should be different.
I am trying to avoid a situation in which we go to great lengths to
define a language - Common Lisp - and then we turn around and say,
``heh, now if you want to write programs and compile them, here are
the rules: if you're going to compile things this way, you can do this,
but you can't do that; if you're going to compile things this other way,
here's what you have to do....''
The issue is to make sure there are at most two languages defined -
1. Common Lisp in Plato's heaven
2. Common Lisp that a compiler understands
I think having a restrictive set of scenarios in which any conforming
Common Lisp program is guaranteed to have the semantics described in
the specification is vastly better than a series of different
languages. I think we have to be explicit in stating that these
restrictive scenarios are ones in which we cannot uniformly state what
every implementation can do uniformly, but that the intention is that
every implementation will try to make the same compilable language
work in all compilation scenarios, not just the ones laid out.
``Random people picking up the Common Lisp standard would get a very bad
impression of the language from seeing a restriction like that, and
it's certainly not consistent with current practice.''
I think they will like less the specification of a number of
languages. And it is consistent, because it is a subset - again, you
mean it isn't the same as current practice. If you want to give the
best impression, then let's just say that there is Common Lisp, and
the compiler is allowed to copy or not allowed to copy in certain
situations, and that otherwise any compilation is
semantics-transparent - any implementation that doesn't provide this
is out of conformance.
-rpg-
∂25-Apr-89 0723 Quinquevirate-mailer Re: Function constants
Received: from cs.utah.edu ([128.110.4.21]) by SAIL.Stanford.EDU with TCP; 25 Apr 89 07:23:33 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA27636; Tue, 25 Apr 89 08:23:28 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11014; Tue, 25 Apr 89 08:23:26 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904251423.AA11014@defun.utah.edu>
Date: Tue, 25 Apr 89 08:23:25 MDT
Subject: Re: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Mon, 24 Apr 89 09:18:58 PDT
> Date: Mon, 24 Apr 89 09:18:58 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
>
> I am trying to avoid a situation in which we go to great lengths to
> define a language - Common Lisp - and then we turn around and say,
> ``heh, now if you want to write programs and compile them, here are
> the rules: if you're going to compile things this way, you can do this,
> but you can't do that; if you're going to compile things this other way,
> here's what you have to do....''
I agree, but it seems like the damage was done when we accepted
proposal QUOTE-SEMANTICS:NO-COPYING. The effect of that proposal is
to make the requirements for COMPILE-FILE more restrictive than the
ones for EVAL and COMPILE, so we are in fact dealing with two
specifications. (All we are trying to deal with as far as function
constants are concerned is COMPILE-FILE.)
-Sandra
-------
∂25-Apr-89 0756 Quinquevirate-mailer No-copying
To: sandra%defun@CS.UTAH.EDU, quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Ok, so let's hear your argument about no-copying. I have to admit that
I had a lot of difficulty understanding the writeup of this proposal.
-rpg-
∂25-Apr-89 0823 Quinquevirate-mailer Re: No-copying
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Apr 89 08:23:31 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA29113; Tue, 25 Apr 89 09:23:32 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11044; Tue, 25 Apr 89 09:23:30 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904251523.AA11044@defun.utah.edu>
Date: Tue, 25 Apr 89 09:23:29 MDT
Subject: Re: No-copying
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: sandra%defun@cs.utah.edu, quinquevirate@SAIL.Stanford.EDU
In-Reply-To: Dick Gabriel <RPG@SAIL.Stanford.EDU>, 25 Apr 89 0756 PDT
I don't know what more I can say about issue QUOTE-SEMANTICS -- it
seems like we've already beaten it to death. I guess people decided
that freeing COMPILE and EVAL from restrictions on what kinds of
objects can appear as constants was more important to them than
maintaining consistency with file compilation.
-Sandra
-------
∂25-Apr-89 0839 Quinquevirate-mailer Re: Function constants
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Apr 89 08:38:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 584260; Tue 25-Apr-89 11:38:32 EDT
Date: Tue, 25 Apr 89 11:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Function constants
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8904251423.AA11014@defun.utah.edu>
Message-ID: <19890425153849.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 25 Apr 89 08:23:25 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Mon, 24 Apr 89 09:18:58 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
>
> I am trying to avoid a situation in which we go to great lengths to
> define a language - Common Lisp - and then we turn around and say,
> ``heh, now if you want to write programs and compile them, here are
> the rules: if you're going to compile things this way, you can do this,
> but you can't do that; if you're going to compile things this other way,
> here's what you have to do....''
I agree, but it seems like the damage was done when we accepted
proposal QUOTE-SEMANTICS:NO-COPYING. The effect of that proposal is
to make the requirements for COMPILE-FILE more restrictive than the
ones for EVAL and COMPILE, so we are in fact dealing with two
specifications.
I don't think it was QUOTE-SEMANTICS:NO-COPYING that did the damage. I
think the damage occurred when COMPILE-FILE itself was admitted into the
language. I see no chance of COMPILE-FILE ever being able to imitate
everything that can be done with EVAL, simply because COMPILE-FILE deals
with two copies of Lisp instead of one. You don't have to do anything
involving constants to see differences between EVAL and COMPILE-FILE.
Macros are enough.
I don't think anyone wants to remove COMPILE-FILE, so instead I think
we have to specify a minimal set of restrictions on what programs can
do -at- -compile- -time- to make them compilable by COMPILE-FILE. This
of course does not restrict what they can do at run time, which can
include calling COMPILE. I don't see any analogy between COMPILE and
COMPILE-FILE, other than that they both call MACROEXPAND and both call
some common subroutine for making machine language instructions. I
think the compiler commitee has been doing a pretty good job recently
of finding a minimal set of restrictions. Dick, I agree with your
contention that the set of restrictions should be minimal, but not that
it should be empty, nor that it should be phrased in a way that is
independent of the idea of compiling or loading a file.
∂25-Apr-89 0859 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 08:59:30 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA01578g; Tue, 25 Apr 89 08:58:29 PDT
Received: by challenger id AA04612g; Tue, 25 Apr 89 08:58:22 PDT
Date: Tue, 25 Apr 89 08:58:22 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904251558.AA04612@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 25 Apr 89 11:38 EDT <19890425153849.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Function constants
I believe that there are some scenarios in which EVAL and COMPILE-FILE
have the same behavior. My question (it's actually a question, not a
disguised contention) is whether these scenarios can be captured with
a simple description, and if so whether that description is
unrestrictive enough.
For example, the description I propose is:
1. A well-formed compilation unit has all type and macro definitions
first, then all function definitions, and then all executable expressions.
2. You must use a fresh Lisp when compile-filing, and you cannot
invoke load or anything but trivial (or *no*) EVAL-WHEN's.
3. You must load a compile-filed file into a fresh copy of the same Lisp.
If you do these, the semantics of EVAL and compile-file on that compilation
unit is the same (?).
Now, once you've described this very safe situation to the user, you
can *go* *on* to say what other restrictions would apply if you relaxed
these conditions - what if you load, what if you do have hairy EVAL-WHEN's.
The idea is that some users will want to know how to construct totally
reliable compilable files without having to learn obscure rules. We
can express these obscure rules, but I also want to see a simple
prescription that does not limit the semantics of Common Lisp.
If the obscure rules are not too obscure, then it is probably best to
just go with them, but I thinkwe currently skate close to the edge with
the obscure rules (this is a compliment, also, to Sandra: we could easily have
gone off the deep end, but didn't.)
-rpg-
∂25-Apr-89 0913 Quinquevirate-mailer Function constants
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Apr 89 09:13:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 584302; Tue 25-Apr-89 12:11:48 EDT
Date: Tue, 25 Apr 89 12:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: <8904251558.AA04612@challenger>
Message-ID: <19890425161207.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 25 Apr 89 08:58:22 PDT
From: Richard P. Gabriel <rpg@lucid.com>
I believe that there are some scenarios in which EVAL and COMPILE-FILE
have the same behavior. My question (it's actually a question, not a
disguised contention) is whether these scenarios can be captured with
a simple description, and if so whether that description is
unrestrictive enough.
For example, the description I propose is:
1. A well-formed compilation unit has all type and macro definitions
first, then all function definitions, and then all executable expressions.
2. You must use a fresh Lisp when compile-filing, and you cannot
invoke load or anything but trivial (or *no*) EVAL-WHEN's.
3. You must load a compile-filed file into a fresh copy of the same Lisp.
If you do these, the semantics of EVAL and compile-file on that compilation
unit is the same (?).
But the argument to EVAL is a form, not a file. So I don't see how you can
even begin to compare the two. There is no concept of compilation units
when dealing with EVAL. I don't think I'm just obnoxiously nitpicking
here, although maybe there is a different way to say what you're saying that
will straighten me out. Could it be that you not talking about EVAL at all,
but about LOAD, and not talking so much about what Common Lisp programs do
as about how to construct files containing Common Lisp programs?
∂25-Apr-89 1325 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 13:25:07 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00407g; Tue, 25 Apr 89 13:24:09 PDT
Received: by challenger id AA04931g; Tue, 25 Apr 89 13:24:02 PDT
Date: Tue, 25 Apr 89 13:24:02 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904252024.AA04931@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 25 Apr 89 12:12 EDT <19890425161207.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Function constants
well, it seems that there is a straightforward way to correspond EVAL
and COMPILE-FILE, which I didn't think was necessary to explicate, but
now I will:
Let S = F1,...,Fn be a series of forms. We ignore well-formedness for
the moment, as well as representation, which I will return to.
Let C = {F1,...,Fn}, a compilation unit with those forms in that
order. Let C' be C compiled with compile-file. A fresh Common Lisp
(CLf) when EVALing each element of S in that order should result in
the ``same observable behavior'' that you get by LOADing C' into a
fresh Common Lisp. Observable behavior includes most everything you
can think of except the representation of the functional (and macral)
objects created and the storage allocation/reclamation behavior.
Presumably each Fi is a textual representation of a form. You can
probably approximate this with LOAD for the EVAL case, but I don't
want to exclude typing them in. Unfortunately, we are in a position to
talk only about LOADing a compiled file rather than having some clear
READ-EVAL-PRINT model for compiled objects.
Now, there is clearly some limitation on what the structure of S (or
C) and each Fi can be in order to achieve the ``same behavior,'' and
we probably need to define observable behavior.
An interesting point is the EQness relationship among objects referred
to in S. In all cases, this EQness refers to the EQness of the objects
in CLf, not in any other Common Lisp that might have been involved in
the creation of S, C, or C'. These relationships ought to be derivable
from examination of the text in S. To achieve the same observable
behavior, we might need to consider equivalence classes of behavior
that is defined by those equivalence relations specified by unspecified
behavior. (That is, if our specification of Common Lisp states that
two things may or may not be EQ in some situation, this defines an
equivalence of behavior.)
Part of the same observable behavior is the observed semantics of
programs that run as a result of EVALing the expressions or LOADing
the compiled code. Again, this is up to equivalence classes.
All I'm wondering is how obnoxious the structuring rules and
equivalence relations must be to make this statement of same behavior.
Thus, I am indeed talking about how to structure files for Common Lisp
programs so that the semantics of those programs is the same whether
or not anything like a compiler has seen them.
-rpg-
∂25-Apr-89 1400 Quinquevirate-mailer Re: Function constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Apr 89 14:00:27 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA12593; Tue, 25 Apr 89 14:56:35 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11328; Tue, 25 Apr 89 14:56:30 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904252056.AA11328@defun.utah.edu>
Date: Tue, 25 Apr 89 14:56:27 MDT
Subject: Re: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Tue, 25 Apr 89 13:24:02 PDT
This makes sense to me. However, I should point out that there are
really two sets of constraints on the ordering of forms within a file:
those that apply to LOAD (of the source file), and some additional
constraints that apply to COMPILE-FILE.
The first set of constraints exists because of the possibility that
the evaluator might always choose to compile forms before executing
them. This includes things like macro definitions, SPECIAL
proclamations, etc. being available before code that requires them
(including any lexically enclosing FUNCTION special forms) is
executed. I can't find anything in CLtL that says this explicitly,
but I was hoping to see some stronger language in the standard saying
that conforming programs must be structured in such a way that they
would work in a compiled-only implementation.
The second set of constraints has more to do with the file compilation
model and EVAL-WHEN, and is oriented towards making sure that
definitions appearing within a file that are needed to correctly
compile the rest of the file are made in the compile-time environment
as well as at load time.
We could require both sets of requirements to be fulfilled by
conforming programs, though. The real question is whether we view the
semantics of Common Lisp as the semantics of programs that can be
compiled with COMPILE-FILE, or whether we view COMPILE-FILE as a kind
of wart on the language that can process only a restricted subset of
conforming programs. I've always taken the former view, but it
appears that I might be in the minoriy.
-Sandra
-------
∂25-Apr-89 1411 Quinquevirate-mailer Re: Function constants
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Apr 89 14:11:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 584702; Tue 25-Apr-89 17:09:10 EDT
Date: Tue, 25 Apr 89 17:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Function constants
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Richard P. Gabriel <rpg@lucid.com>, quinquevirate@sail.stanford.edu
In-Reply-To: <8904252056.AA11328@defun.utah.edu>
Message-ID: <19890425210929.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 25 Apr 89 14:56:27 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
We could require both sets of requirements to be fulfilled by
conforming programs, though. The real question is whether we view the
semantics of Common Lisp as the semantics of programs that can be
compiled with COMPILE-FILE, or whether we view COMPILE-FILE as a kind
of wart on the language that can process only a restricted subset of
conforming programs. I've always taken the former view, but it
appears that I might be in the minoriy.
The former view is fine with me. My comments were directed more towards
not muddling COMPILE and COMPILE-FILE. In other words, the semantics of
programs that can be compiled with COMPILE-FILE includes that those
programs can call COMPILE on lambda expressions that could not have been
part of the macro expansion of DEFUN forms appearing in a file to be
compiled. That doesn't sound very clear, re-reading it, but from past
mail you should know what I mean. I'm sending this message mainly to
clarify that if you are in the minority, I'm not one of the majority.
∂25-Apr-89 1924 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 19:24:34 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01008g; Tue, 25 Apr 89 19:24:08 PDT
Received: by challenger id AA05566g; Tue, 25 Apr 89 19:24:00 PDT
Date: Tue, 25 Apr 89 19:24:00 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904260224.AA05566@challenger>
To: sandra%defun@cs.utah.edu
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 25 Apr 89 14:56:27 MDT <8904252056.AA11328@defun.utah.edu>
Subject: Function constants
well, I think we're pretty much in synch here. The question of macros
being defined or available before the code that uses them is an
interesting one. It is easy to imagine a programming environment in
which recompilation of all required definitions is done whenever a
macro changes.
So, should we include structuring information? If so, should we only
worry about which definitions should appear before which others? What
do we say about recursive loads and compiles? Presumably the
Lisp-symbol-redefinition covers some bad case; what about readtables
and packages? (I guess something is already said about packages.)
Should we worry about loading compiled files into images in which
compilation already happened, or should we state that we can only
guarantee semantics in the fresh Lisp case?
Regardless of what we do, we need to state that what is actually
sensible in some particular program structure will depend on the
implementation. Possibly we should indicate some things that might
work(?).
What is the resolution of function constants? I prefer these solutions in
this order:
1. Allow them to be used everywhere
2. Allow them to be allowed nowhere, but allow implementations to
extend (that is, leave it undefined).
3. Allow some mixtures in some cases.
-rpg-
∂25-Apr-89 2020 Quinquevirate-mailer Re: Function constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Apr 89 20:20:21 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA24885; Tue, 25 Apr 89 21:19:49 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11594; Tue, 25 Apr 89 21:19:46 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904260319.AA11594@defun.utah.edu>
Date: Tue, 25 Apr 89 21:19:44 MDT
Subject: Re: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Tue, 25 Apr 89 19:24:00 PDT
> Date: Tue, 25 Apr 89 19:24:00 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
>
> It is easy to imagine a programming environment in
> which recompilation of all required definitions is done whenever a
> macro changes.
Hmmm. That seems like a programming environment issue, except that
the current version of issue COMPILE-ENVIRONMENT-CONSISTENCY (which we
haven't voted on yet) effectively says that macro definitions don't
affect code once it has been compiled. I think such a programming
environment would be a legitimate extension if users had to set a
magic switch to get this behavior, though.
> So, should we include structuring information? If so, should we only
> worry about which definitions should appear before which others?
I admit to being rather partial to the way this is now handled in the
draft of section 4.2 I've been working on. It talks about what kind
of information is needed by the compiler in the subsection on
compilation semantics, and then the subsection on file compilation
talks about what constructs make information available to the compiler
during processing by COMPILE-FILE. In other words, we've specified a
requirement on implementations. I've kind of been assuming that the
behavior of conforming programs is covered under the part of the
conformance language that says that conforming programs have to depend
on the semantics of the language as described in the standard, and
that no additional requirements on conforming programs were necessary
as far as compilability is concerned.
> What do we say about recursive loads and compiles?
I think it ought to be allowed and therefore we don't need to say
anything. (I suspect a couple of implementations probably break if
COMPILE-FILE is invoked recursively, but I think that's a bug.)
> Presumably the
> Lisp-symbol-redefinition covers some bad case; what about readtables
> and packages? (I guess something is already said about packages.)
I'm not sure exactly what aspects of readtables and packages you're
referring to here. My writeup for section 4.2 does explicitly mention
manipulation of *READTABLE* and *PACKAGE* as situations where
EVAL-WHEN is useful for making sure that COMPILE-FILE reads the input
file properly, though.
> Should we worry about loading compiled files into images in which
> compilation already happened, or should we state that we can only
> guarantee semantics in the fresh Lisp case?
I don't think there's any problem with specifying the semantics of
loading compiled files into "non-fresh" images. Do you have some
particular aspect in mind that you think is not well-specified?
> What is the resolution of function constants?
Well, unless somebody writes up another proposal, we're stuck with
CONSTANT-FUNCTION-COMPILATION:NO, which means they're OK for COMPILE
and EVAL but the behavior of COMPILE-FILE is unspecified.
-Sandra
-------
∂25-Apr-89 2055 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 20:55:07 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01116g; Tue, 25 Apr 89 20:54:57 PDT
Received: by challenger id AA05696g; Tue, 25 Apr 89 20:54:50 PDT
Date: Tue, 25 Apr 89 20:54:50 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904260354.AA05696@challenger>
To: sandra%defun@cs.utah.edu
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 25 Apr 89 21:19:44 MDT <8904260319.AA11594@defun.utah.edu>
Subject: Function constants
Well, I see that your first draft of 4.2 has appeared in my mail (at
SAIL), so I think I should read it before continuing the discussion.
Let me say, though, that I prefer to leave function constants
undefined in all contexts rather than defined in some and undefined in
others.
-rpg-
∂25-Apr-89 2056 Quinquevirate-mailer status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 20:56:20 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06267; Tue, 25 Apr 89 20:57:02 PDT
Message-Id: <8904260357.AA06267@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA06267; Tue, 25 Apr 89 20:57:02 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 25 Apr 89 23:49
To: quinquevirate@sail.stanford.edu
Subject: status
I'm working on completing incorporating the issues to the exclusion
of everything else. I've come across several questions and problems
with the issues that I will compile (not eval or compile-file;-)
and get resolution on when I'm done with all of them.
This message is to let you know that there will be more things coming
to you at a faster rate as soon as I complete wading through these
*&&↑%$# issues.
∂01-May-89 1631 Quinquevirate-mailer Re: new cleanups
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 May 89 16:30:54 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 01 MAY 89 16:10:29 PDT
Date: 1 May 89 16:10 PDT
From: masinter.pa@Xerox.COM
Subject: Re: new cleanups
In-reply-to: your message of Fri, 28 Apr 89 18:38:05 MDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: quinquevirate@sail.stanford.edu
Message-ID: <890501-161029-3020@Xerox>
I think we should just make what I think is the only reasonable translation:
"relatively useless" means "is not required by this standard to have any effect"'.
I don't think we need a cleanup issue to do that.
- - - - - -
GV-Info: sandra%defun@cs.utah.edu at 28-Apr-89 17:38:51 from AG
Return-Path: <sandra%defun@cs.utah.edu>
Received: from cs.utah.edu ([128.110.4.21]) by Xerox.COM ; 28 APR 89 17:38:13 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11376; Fri, 28 Apr 89 18:38:09 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA13450; Fri, 28 Apr 89 18:38:06 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904290038.AA13450@defun.utah.edu>
Date: Fri, 28 Apr 89 18:38:05 MDT
Subject: new cleanups
To: masinter.pa
Is the cleanup committee still in business? I'd like to open a new
issue to clarify what *EVALHOOK* is supposed to do in compiled-only
implementations, having just run into the problem while writing a new
evaluator. (CLtL just says it's "relatively useless", whatever that
means.) I'm not sure if this issue falls in the domain of cleanup or
compiler -- I you think I ought to handle it in compiler I'll send
it there.
-Sandra
-------
∂01-May-89 1706 Quinquevirate-mailer Re: new cleanups
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 May 89 17:06:00 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03113; Mon, 1 May 89 18:06:04 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03477; Mon, 1 May 89 18:05:59 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905020005.AA03477@defun.utah.edu>
Date: Mon, 1 May 89 18:05:58 MDT
Subject: Re: new cleanups
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
quinquevirate@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 1 May 89 16:10 PDT
That would be fine, except that there have also been a suggestion
(from Kim Barrett) that perhaps EVALHOOK and friends really ought to
be deprecated, and another one (from Pitman and the Cloe implementors
at Symbolics) that they should either be removed from the language
entirely or somehow marked as being an optional extension, along with
other debugging tools such as STEP and TRACE and the top loop
variables. Certainly any action like that should be done by a vote of
the full committee rather than handled as an editorial change.
Also, I'd like to see a clarification that STEP need not be implemented
in terms of EVALHOOK (CLtL page 323).
-Sandra
-------
∂01-May-89 2229 Quinquevirate-mailer Re: new cleanups
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 May 89 22:29:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 MAY 89 22:28:49 PDT
From: masinter.pa@Xerox.COM
Date: 1 May 89 22:27:46 PDT
Subject: Re: new cleanups
In-reply-to: sandra%defun@cs.utah.edu's message of Mon, 1 May 89 18:05:58
MDT, <8905020005.AA03477@defun.utah.edu>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: masinter.pa@Xerox.COM, quinquevirate@sail.stanford.edu
Message-ID: <890501-222849-4174@Xerox>
I personally am not interested in bringing forward "cleanups" at
this point that would remove STEP and TRACE and the top loop variables.
There's two possibilities: either these are minor clarifications based
on the transition of CLtL from a "user guide" to a "specification",
which we can just handle and propose en masse as "the only reasonable
interpretation of CLtL as a standard", or else these are proposals
for major changes which remove features.
It is a serious mistake to believe that "deprecating" a feature removes
the responsibility of specifying what it does.
∂02-May-89 0604 Quinquevirate-mailer Re: new cleanups
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 May 89 06:04:44 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA28684; Tue, 2 May 89 07:04:50 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA14332; Tue, 2 May 89 07:04:48 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905021304.AA14332@defun.utah.edu>
Date: Tue, 2 May 89 07:04:46 MDT
Subject: Re: new cleanups
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
quinquevirate@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 1 May 89 22:27:46 PDT
I don't believe anybody has been arguing that deprecation is a
substitute for clarification. But in this case, "the only reasonable
interpretation of CLtL" seems to be that users can't rely on EVALHOOK
doing anything meaningful. Does such a feature really have any place
in the language?
-Sandra
-------
∂03-May-89 0302 Quinquevirate-mailer Status as of 5/3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 89 03:01:07 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA13930; Wed, 3 May 89 03:01:54 PDT
Message-Id: <8905031001.AA13930@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA13930; Wed, 3 May 89 03:01:54 PDT
From: chapman%37.975.DEC@decwrl.dec.com
Date: 3 May 89 05:59
To: quinquevirate@sail.stanford.edu
Subject: Status as of 5/3
Following is a status of what's happening with the standard.
Please let me know if this list differs from your expectations.
All clean-up issues that I didn't find problems or questions
with have been included. The next message you get is the list of
issues followed by the files numbers that were changed as a result of each
issue. To find the change that specifically pertains to the issue
you're tracing, look in the source file for "\issue{<issue name>"
or in the hardcopy for "The following is from issue: <issue name>.
The file number to file name translation is in another mail message
you will receive.
What I plan to do next includes removing the Side Effects section
from all the functions that aren't checked out (and then remove it
from that functions that are checked out when they come back to me).
Also I will be including the issues that may be approved in June,
and the issues that I haven't included because of outstanding questions.
I will complete this job when all the sections are checked back to me
again. I will send you the files that have been changed for your review
(so you won't have to go through another complete review if you don't
want to) after I have added the new issues.
I will be creating a list of all places in the standard where error
terminology is needed and suggestions about which type of error
seems to belong there.
I believe we are responsible for at least part of the agenda for the
June meeting. Any suggestions about how we should present what we've
done?
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application RPG has created a new
draft, Moon has reviewed. KC is reviewing
now.
1.2 Organization of the Document Done
1.3 Referenced Publications Done
1.4 Definitions Done
1.5 Compliance KC has created a new
issue to be reviewed and voted on in June or
before. The issue contains all the compliance
information, not just a subset of it, and incorporates
comments from the Germans and information from the
international Pascal standard.
1.6 Language Extensions KC has created a new issue.
Chapter 2. Objects and Types
CONTENTS
2.1 Introduction Done
2.2 Types Moon reviewed, KC
included comments, Moon responded to inclusions,
KC is including responses and sending Moon new copy
to review.
2.3 Classes There have been some
comments about sections 2.3, 2.4, and/or 2.5. These
have been forwarded to RPG.
2.4 Slots Done
2.5 Objects Done
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader KC is including Loosemore
comments. These will go to Masinter by the end of
this week.
3.2 Object Syntax same as 3.1
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model Moon reviewed, KC is
including comments. Will return to Moon by the
end of this week.
4.2 Compilation RPG is reviewing Loosemore's
draft.
Chapter 5. Other Topics
CONTENTS
5.1 Errors RPG is rewriting.
5.2 Input/Output Masinter is reviewing.
5.3 Interface with the Programming Environment Masinter is reviewing.
5.4 Generalized Reference Masinter is reviewing.
Chapters 6 and 7. Catalog of Defined Names
CONTENTS
6.1 Introduction KC is including comments,
the RPG will review.
The following list contains the names of groups of functions as they
appear in CLtL, CLOS, and the Condition System documents.
CLOS RPG is reviewing.
PREDICATES Masinter is reviewing.
STRINGS Masinter is reviewing.
SEQUENCES Masinter is reviewing.
LISTS Masinter is reviewing.
NUMBERS Masinter is reviewing.
STRUCTURES GLS is reviewing (in the
US mail to GLS).
SYMBOLS same as STRUCTURES.
HASH-TABLES same as STRUCTURES.
ARRAYS same as STRUCTURES.
TYPES same as STRUCTURES.
DECLARATIONS same as STRUCTURES.
IO Masinter 6/14/89
STREAMS Masinter 6/14/89
FILE Masinter 6/14/89
CONTROL Masinter 6/14/89
PROGRAM Masinter 6/14/89
MISC Masinter 6/14/89
ERRORS RPG 6/14/89
MACROS Moon 6/14/89
PACKAGES Moon 6/14/89
CHARACTERS Moon 6/14/89
EVALUATOR Moon 6/14/89
Glossary KC is including KMP
comments, will send to RPG by the end of this week.
RPG: 1.1, 4.2, 6.1, 5.1, CLOS, Errors, Glossary, proliferating error terms
Masinter: 3.1, 3.2, 5.2, 5.3, 5.4,
PREDICATES, STRINGS, SEQUENCES, LISTS, NUMBERS, IO, STREAMS,
FILE SYSTEM INTERFACE, CONTROL STRUCTURE, PROGRAM STRUCTURE,
MISCELLANEOUS FEATURES
Moon: 2.2, 4.1, MACROS, PACKAGES, CHARACTERS, EVALUATOR
GLS: STRUCTURES, SYMBOLS, HASH-TABLES, ARRAYS, TYPES, DECLARATIONS
∂03-May-89 0402 Quinquevirate-mailer List of issues and which files were changed as a result of each
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 89 04:01:21 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16965; Wed, 3 May 89 04:02:17 PDT
Message-Id: <8905031102.AA16965@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA16965; Wed, 3 May 89 04:02:17 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 May 89 06:01
To: quinquevirate@sail.stanford.edu
Subject: List of issues and which files were changed as a result of each
Notes:
1. DD means included in standard, files numbers or names that are changed are
listed with the issue.
2. File numbers or names in parens (like under issue FUNCTION-NAME) mean that the file
had a pointer to another file that was actually changed.
3. Any file number in the following list that isn't preceded by a letter
should be preceded by the letter `f'. All file names (like `chapter7')
should be followed by `.tex'.
Issues not in this list on 4/19:
TYPE-OF-UNDERCONSTRAINED:
DECLARE-TYPE-FREE:
TEST-NOT-IF-NOT:
DD -- Issue: ADJUST-ARRAY-DISPLACEMENT
Version 4 by Masinter, 23-Nov-87
ADJUST-ARRAY-DISPLACEMENT -- passed March 88 meeting 230
ADJUST-ARRAY-DISPLACEMENT.TXT;1 -- clarifies what happens when
a displaced array is adjusted.
f028
DD -- Issue: ADJUST-ARRAY-FILL-POINTER
Edit history: 15-Mar-88, Version 1 by Pitman
DD -- ADJUST-ARRAY-FILL-POINTER -- passed June 88 meeting 291
DUA1:[CHAPMAN.FROM-OFFICE]ADJUST-ARRAY-FILL-POINTER.TXT;1 -- clarifies what
happens when an array with a fill pointer is adjusted.
f028
???DD -- Issue: ADJUST-ARRAY-NOT-ADJUSTABLE not complete yet(4/89)
11-Jan-89, Version 4 by Pitman
Adjustable option explanation.
395,029,028
DD -- Issue: APPLYHOOK-ENVIRONMENT
Masinter, 10-Jan-89, Version 2
Remove ENV argument from APPLYHOOK.
257,256
DD -- Issue: AREF-1D
14-Nov-87, Version 7, by Masinter (update discussion)
DD -- AREF-1D -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]AREF-1D.TXT;1 -- new function to access arrays
in row major order.
f750, f599, chapter7, ARRAYS
DD -- Issue: ARGUMENTS-UNDERSPECIFIED
21-Sep-88, Version 4 by Masinter
Specify arguments to functions completely.
371,399,401,406,409,475,598, 502, 550, 552, 553, 554, 557, 558, 592
DD -- Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Version 9, 31-Oct-88, JonL (major re-wording to accommodate
Eliminate distinction between type specifiers for declaration and for
discrimination.
s2200, 689, 043, 661, 751, 752, Chapter7, ARRAYS
DD -- Issue: ASSOC-RASSOC-IF-KEY
23-Nov-87, Version 4 by Masinter
ASSOC-RASSOC-IF-KEY -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]ASSOC-RASSOC-IF-KEY.TXT;1 -- add :key to if, if-not
f056, f544
DD -- Issue: BREAK-ON-WARNINGS-OBSOLETE
8-Apr-89, Version 2 by Masinter (as amended; update discussion)
806, sa300, 252, 805, 841
***Section 5.1 is out, won't do this one until that section comes back from
RPG***
Issue: CLOS-CONDITIONS
10-Mar-89, Version 4 by Pitman (remove unsupported options)
DD -- Issue: CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY
Masinter, 12-Jan-89, Version 2
Glossary, 171, 310, 408
DD -- Issue: CLOSED-STREAM-OPERATIONS
5-Dec-88, Version 5 by Masinter (separate other issues)
Clarify what operations can be performed on a closed stream.
685,630,171,494,428,497,(495,496,498,499,500),451,(270,227,321,246),481,526,226.
DD -- Issue: COLON-NUMBER
Edit history: 22-Oct-87, Version 1 by Pitman
DD -- COLON-NUMBER -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]COLON-NUMBER.TXT;1 -- :<potential number> is an
error.
s3100
DD -- Issue: COMMON-TYPE
Edit history: Version 1, 20-Mar-89, by Moon
s2200, 175, sa300
DD -- Issue: COMPILER-WARNING-STREAM
Version 6 by Masinter, 5-Jun-87, minor formatting
COMPILER-WARNING-STREAM -- passed June 88
compile and compile-file can issue warnings through *error-output*.
f176, f177
DD -- Issue: COMPLEX-ATAN-BRANCH-CUT
Edit history: Version 1, 13-Dec-88, Steele
Replace a formula.
(059), 053
DD -- Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Edit history: Version 1, 14-Sep-88, Moon
Add a contagion rule.
s2200 (now in s6100)
DD -- Issue: COPY-SYMBOL-COPY-PLIST
Edit history: 10-Jan-89, Version 1 by Margolin
192
** need new version of this one
Issue: COPY-SYMBOL-PRINT-NAME
DD -- Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED
DATA-TYPES-HIERARCHY-UNDERSPECIFIED -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DATA-TYPES-HIERARCHY-UNDERSPECIFIED.TXT;1 --
make some type disjoint.
s2200, f212
DD -- Issue: DECLARATION-SCOPE:NO-HOISTING
Version 4, JonL, 15-Nov-88 add 2nd proposal; major rewrite.
Clarify scope of declaration at head of special form or lambda expression.
202, Glossary, 356, 528, 229, 283, 444, 232, 234, 235, s4100, 527
DD -- Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89, Pierson (Pitman comments)
Clarify that references to array elements are assumed to satisfy the
exact declared element type.
s2200
DD -- Issue: DECLARE-FUNCTION-AMBIGUITY
#4, 5-Dec-88, Masinter (append Oct x3j13 comments)
Redefine (FUNCTION ...).
202
DD -- Issue: DECLARE-MACROS
DECLARE-MACROS -- passed March 88 meeting
5-Feb-88, Version 3 by Pitman
DUA1:[CHAPMAN.FROM-OFFICE]DECLARE-MACROS.TXT;1 -- don't let macros expand
into declares.
f202, f527
DD -- Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT
30-Sep-88, Version 2 by Masinter
204, s5300
DD -- Issue: DEFMACRO-LAMBDA-LIST
10-Apr-89, V.4 Masinter (forgot an amendment)
209
DD -- Issue: DEFPACKAGE
Version 7, 2-Nov-88, JonL
753, chapter6, s6100, PACKAGES
DD -- Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
8-Jan-89, Version 3, Masinter
Allow &KEY keyword arguments in constructor forms of DEFSTRUCTs and
...
212
DD -- Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Revision 1 by Skona Brittain 05/13/88
212
DD -- Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
V3, 7 Dec 1988, Masinter
Clarify print function inheritance.
212
DD -- Issue: DEFSTRUCT-REDEFINITION
Version 3 by Masinter 6-Feb-89 as per Jan 89 X3J13 amendment
212
**need new version of this one
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-JAN-89
DD -- Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Edit history: Revision 1 by Skona Brittain 05/13/88
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER.TXT;1 -- allow
a call to defstruct to have no slot-descriptions.
f212
DD -- Issue: DEFVAR-DOCUMENTATION
23-Nov-87, Version 2 by Masinter
DEFVAR-DOCUMENTATION -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DEFVAR-DOCUMENTATION.TXT;1 -- documentation part
of these forms isn't evaluated.
f215, f210, f206
DD -- Issue: DEFVAR-INIT-TIME
29-Mar-87, Version 2 by Masinter
DEFVAR-INIT-TIME -- passed June 87 meeting
clarifies time at which defvar initialization occurs.
f215
DD -- Issue: DEFVAR-INITIALIZATION
Version 4 by Masinter 5-Jun-87
DEFVAR-INITIALIZATION -- passed June 87 meeting
clarifies what happens if an init value isn't provided.
f215
DD -- Issue: DESCRIBE-INTERACTIVE:NO
15-Nov-88, Version 4 by Pierson, two-proposal version
Clarify DESCRIBE's interactive behavior.
911 (generic function describe), 223 (normal function describe)
DD -- Issue: DESCRIBE-UNDERSPECIFIED
Version 2, 9-Apr-89, Masinter (as per Mar 89 X3J13)
911 (generic function describe deleted), 223 (normal function describe
augmented with changes from DESCRIBE-INTERACTIVE:NO and this issue), 754,
CLOS, Chapter6
DD -- Issue: DESTRUCTURING-BIND
29-Mar-89, Version 3, by Moon, amended based on poll
755, Chapter6, MACROS, is this affected by DEFMACRO-LAMBDA-LIST and
DOTTED-MACRO-FORMS?
DD -- Issue: DISASSEMBLE-SIDE-EFFECT
Version 3 by Pierson 1/21/88
DISASSEMBLE-SIDE-EFFECT -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DISASSEMBLE-SIDE-EFFECT.TXT;1 -- disassemble should
never install the newly-compiled function.
f228
DD -- Issue: DO-SYMBOLS-DUPLICATES
Version 3 by Masinter 23-Nov-87
DO-SYMBOLS-DUPLICATES -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DO-SYMBOLS-DUPLICATES.TXT;1 -- the body may be
executed more than once for some symbols.
f232
DD -- Issue: DOTTED-MACRO-FORMS
15-Nov-88, Version 3 by Pitman (revive allow, flush disallow)
Define that it is permissible for a macro form (or subform)
to be a dotted list when "&REST var" or ". var" is used to match
it.
209, does this effect DESTRUCTURING-BIND?
DD -- Issue: DRIBBLE-TECHNIQUE
14-Feb-88, Version 2 by Masinter
DRIBBLE-TECHNIQUE -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DRIBBLE-TECHNIQUE.TXT;1 -- clarify that dribble
isn't portable.
f239
DD -- Issue: DYNAMIC-EXTENT
05-Apr-89, Version 4 by Pitman and Steele (changes per X3J13)
202
DD -- Issue: EQUAL-STRUCTURE
15-Mar-89, Version 7 by Masinter (amended as per vote at Jan 89 X3J13)
250, 249
DD -- Issue: EVAL-OTHER
8-Jun-88, Version 2 by Masinter (correct typo, add to discussion)
s4100
DD -- Issue: EXIT-EXTENT:MINIMAL
Version 7, 4-Apr-89, Moon, amend per X3J13 Mar-89, and make
rationale and examples consistent with that
Glossary, 317, 578, 680, (no changes to catch, block, or tagbody),
examples added to unwind-protect (697)
DD -- Issue: EXPT-RATIO
Version 3, 31-Oct-88, Masinter (fix typo)
Clarify that (sqrt (expt x 3)) is not equivalent to (expt x 3/2)
and that page 211 rules.
f*.exp
DD -- Issue: FIXNUM-NON-PORTABLE
Version 6, 17-Mar-89, Masinter (incorporate amendments correctly)
s2200, 040, 440
DD -- Issue: FLET-DECLARATIONS
Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter)
FLET-DECLARATIONS -- passed March 88 meeting
allow declarations in flet, labels, and macrolet.
f283
DD -- Issue: FLET-IMPLICIT-BLOCK
Version 6 by Masinter 5-Jun-87
FLET-IMPLICIT-BLOCK -- passed June 87 meeting
DUA1:[CHAPMAN.FROM-OFFICE]IMPLICIT-BLOCKS.TXT;1 -- put implicit blocks around
flet, labels... (this is the flet-implicit-block proposal)
f283, f209, f211, f208, f213
DD -- Issue: FORMAT-ATSIGN-COLON
Version 4 by Masinter 5-Jun-87
FORMAT-ATSIGN-COLON -- passed June 87 meeting
clarifies the @: relationship.
f293
DD -- Issue: FORMAT-COLON-UPARROW-SCOPE
version 3: Masinter, 5 February 1988
FORMAT-COLON-UPARROW-SCOPE -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]FORMAT-COLON-UPARROW-SCOPE.TXT;1 -- iteration
termination within format.
f293
DD -- Issue: FORMAT-COMMA-INTERVAL
Version 2, Masinter, 15-Jun-87
FORMAT-COMMA-INTERVAL -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]FORMAT-COMMA-INTERVAL.TXT;1 -- add another argument
to the format directives for printing numbers in certain radices that
says how many digits are printed between commas when printing the number
out: 100,000,001 could be 10,0000,0001?
f293
DD -- Issue: FORMAT-E-EXPONENT-SIGN
V2 Masinter, 2-Oct-88 (change issue name)
Specify that ~E always prints a plus or minus sign in front of the
exponent.
293
DD -- Issue: FORMAT-OP-C
11-Jun-87, Version 5 release to X3J13
FORMAT-OP-C -- passed June 87 meeting
change behavior of ~C.
293
DD -- Issue: FORMAT-PRETTY-PRINT
Version 7 by Pierson 11/15/88 "does" => "does not"
Specify that FORMAT does not rebind any of the printer control
variables (*PRINT-...) except as follows:
293, 520, 517, 524 (added example)
DD -- Issue: FUNCTION-CALL-EVALUATION-ORDER
(passed October 1989)
Version 1 by Clinger (22 March 1988)
s4100
***check constantly***
DD -- Issue: FUNCTION-COMPOSITION
10-Feb-89, Version 5 (as amended by X3J13 Jan 89)
756, chapter6, sequences (constantly not added, still checking)
DD -- Issue: FUNCTION-DEFINITION
10-Feb-89, Version 3, as amended Jan 89 X3J13
757, chapter6, miscellaneous-features
DD -- Issue: FUNCTION-NAME:LARGE (amended, I amended myself, maybe new
copy will come out)
Version 1, 23-Jan-89, by Moon
(based on discussion at X3J13 meeting)
s6100, macros2, macros2a, 758, 599, 263, (291), 413, 299, 908, 913, 907,
910, 919, 912, 214, 176, 228, 202, 682, 241
**need help on one point in this issue**
DD -- Issue: FUNCTION-TYPE
4-Sep-88, Version 12 by Masinter
FUNCTION-TYPE -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]FUNCTION-TYPE.TXT;1 -- clarify what the term
`function' means. Clarify the role of the function type specifier, specify
what the type function is disjoint from.
s2400, s2200, s2300, s4100, f414, f034, f298, f300, f689, f299, f263, f664,
f599, f174, f393
DD -- Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
#3, 7-Dec-88, Masinter
Specify that a declaration of the form
(ftype (function (arg0-type arg1-type ...) val-type) f))
implies that any call of the form (f arg0 arg1 ...) within the scope of
the declaration can be treated as if it were
s2200
DD -- Issue: FUNCTION-TYPE-KEY-NAME
Version 3, 13-Feb-88 Masinter
FUNCTION-TYPE-KEY-NAME -- passed June 88 meeting
specifies how the &key arguments are supplied to the type function.
s2400
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88 Masinter (add to discussion)
Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.
s2200
DD -- Issue: GENSYM-NAME-STICKINESS
20-Mar-89, Version 3 by Pitman (make it a variable)
302, sa400, 759, chapter6, symbols
DD -- Issue: GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89, as amended Jan 89 X3J13
(306), 595, (309), 597
DD -- Issue: GET-SETF-METHOD-ENVIRONMENT
Version 5 13-Jul-87, by Masinter
GET-SETF-METHOD-ENVIRONMENT -- passed June 87 meeting
DUA1:[CHAPMAN.FROM-OFFICE]GET-SETF-METHOD-ENVIRONMENT.TXT;1 -- add environment
argument to get-setf-method.
f313, f208, f207
DD -- Issue: HASH-TABLE-ACCESS
05-Apr-89, version 3 by Pitman (changes per x3J13)
760, 761, 762, 763, chapter6, hash-tables
DD -- Issue: HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Masinter (add comment to discussion)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
764, 765, chapter7, hash-tables, packages
DD -- Issue: HASH-TABLE-TESTS
8-Dec-88 Version 2 by Masinter
With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
can expect EQUALP to be a true equivalence function, and thus a suitable
401, s6100
DD -- Issue: IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Masinter (1st => 3rd person)
Redefine the branch cut for two-argument ATAN, covering
the cases where there is or is not a minus zero, and then redefine *all*
other functions that have branch cuts in terms of two-argument ATAN.
367, 623, 503, (059), 053, 260, (054), 615, 023
DD -- Issue: IMPORT-SETF-SYMBOL-PACKAGE
Version 5 to X3J13
IMPORT-SETF-SYMBOL-PACKAGE -- passed June 87 meeting
clarifies action of import on home package.
f325
DD -- Issue: IN-SYNTAX
Version 3, 9-Apr-89, Masinter
(Include discussion from Version 1)
177, 364
DD -- Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
8-Nov-87, Version 8 by Moon
KEYWORD-ARGUMENT-NAME-PACKAGE -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]KEYWORD-ARGUMENT-NAME-PACKAGE.TXT;1 -- allow keywords
to be in other packages besides the keyword package.
s4100, there are other UNMARKED changes sprinkled throughout the document
that seek to avoid confusion between keyword and keyword name.
DD -- Issue: LAST-N
12-Mar-88, Version 2 by Pitman
LAST-N -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]LAST-N.TXT;1 -- add a new argument to last that
specifies the number of elements of the list to return.
f342
DD -- Issue: LCM-NO-ARGUMENTS
Edit history: Version 1, Guy Steele 10/17/88
Define (lcm) to return the integer 1.
343
DD -- Issue: LISP-PACKAGE-NAME
9-Apr-89, version 2 by Masinter, incorporate
changes per Mar 89 amendments.
s2200, 326, 403, 484, 753
modified examples in the following files: 279, 280, 303, 325, 488,
490, 829, 335, 385, 485, 603, 690, 691, 696
DD -- Issue: LISP-SYMBOL-REDEFINITION
Masinter, Version 6, 9-Apr-89, make Mar 89 X3j13 amendments
s2200, 214, 209, 212, 907, 213, 527, 682, 202, 356, 283
***may need more work on this one, notes in issue***
DD -- Issue: LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, by Moon, fix referenced proposal name
366, eval-when-non-top-level
DD -- Issue: LOOP-AND-DISCREPANCY
Edit history: Version 1, 15-Mar-88 by Steele
385
DD -- Issue: MACRO-FUNCTION-ENVIRONMENT
Version 2, Masinter, 8-Jun-88, (as per cleanup discussion)
MACRO-FUNCTION-ENVIRONMENT -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]MACRO-FUNCTION-ENVIRONMENT.TXT;1 -- add an
environment argument to macro-function.
f390, f209
*** need v3*** Issue: MAKE-PACKAGE-USE-DEFAULT
Masinter, 8-Oct-88 (version 2)
Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
adopted, and IN-PACKAGE, if IN-PACKAGE-FUNCTIONALITY is not
adopted) so that the default for the :USE keyword is
DD -- Issue: MAPPING-DESTRUCTIVE-INTERACTION
09-Jun-88, Version 2 by Pitman
Clarify that it in general is an error (the effect is not defined
but in general no error will be signalled) for code executed during a
s6100, 027, 056, 196, (216), 568, (230), (217), 232, 234, 254,
259, 275, 336, 385, 414, 419, 424, 427, 431, (458), 459), 594,
596, 652, 655, 658, 692, 507, 544, 564, 590, 621, 654, 684, 764, 765,
710, 713
DD -- Issue: NTH-VALUE
17-Mar-89, Version 5, Masinter (as amended)
766, chapter7, control-structure
DD -- Issue: PACKAGE-CLUTTER
17-Mar-89, Version 7 by Masinter (as amended Jan 89 X3J13)
s2200
DD -- Issue: PACKAGE-DELETION
21-Nov-88, Version 5 by Masinter
Introduce the function DELETE-PACKAGE, described as follows:
767, chapter6, packages
DD -- Issue: PACKAGE-FUNCTION-CONSISTENCY
17-Mar-89, Version 4, by Moon, correct amended wording
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
403, 326, 279, 767, 335, 691, 261, 699, 696, 753, 690, 325, 603, 602,
485, 486, 488, 489, 232
***still a question about unuse-package and use-package
DD -- Issue: PATHNAME-UNSPECIFIC-COMPONENT
17-Mar-89, Version 2 by Masinter (as amended)
Permit :UNSPECIFIC as a value of all
fields of a pathname for file systems in which it makes sense.
s2200, 404, 428, 497, 700
DD -- Issue: PATHNAME-STREAM
Version 6 by Masinter 14-Nov-87
PATHNAME-STREAM -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]PATHNAME-STREAM.TXT;1 -- clarify that only a stream
associated with a file can be used in pathname functions.
macros2, f685, f493, f428, f497, f451, f494,
f481, f711, f573, f218, s6100 (by changing macros2.tex)
changed conditions section in all the above files.
what is OPEN-STRING-STREAM???
DD -- Issue: PATHNAME-SYMBOL
Version 5 by Masinter 5-Feb-88, fix minor typo
PATHNAME-SYMBOL -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]PATHNAME-SYMBOL.TXT;1 -- disallow symbols for
lots of fucntions where pathnames are required (e.g. (load 'foo) -> (load
"foo)
macros2, f494 (examples, unmarked), f493, f451
** this one may come up again?
Issue: PEEK-CHAR-READ-CHAR-ECHO
8-Oct-88, Version 3 by Pitman & Masinter
Ammend the description of READ-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), the character
will be echoed on the stream the first time those characters are seen.
DD -- Issue: PRINC-CHARACTER
29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
PRINC-CHARACTER -- passed June 87 meeting
clarify what princ on a character means.
f714
DD -- Issue: PRINT-CIRCLE-STRUCTURE
Version 4, Masinter, 17-Mar-89 (as amended)
When *print-circle* is T, a user defined print-function or method on
PRINT-OBJECT can print
objects to the supplied stream using WRITE, PRIN1, PRINC, or FORMAT
519, 212, 929,
DD -- Issue: PUSH-EVALUATION-ORDER
Version 5, 25-Nov-87, Larry Masinter
PUSH-EVALUATION-ORDER -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]PUSH-EVALUATION-ORDER.TXT;1 -- specified the
evaluation order of generalized references within macros.
f537, s5400, f315, f566, f327, f604, f599, f506, f344, f207, f807, f810,
f813, f803
DD -- Issue: RANGE-OF-COUNT-KEYWORD
09-Oct-88, Version 3 by Pitman
Clarify that for the functions ...
568, 658
DD -- Issue: RANGE-OF-START-AND-END-PARAMETERS
Edit history: 14-Sep-88, Version 1 by Pitman
Clarify that for functions permitting a parameter named START, START1,
or START2 which delimits the beginning point in a sequence to be
considered for some operation, that paremeter must be a non-negative
integer. If the argument is optional or key (as is the case for all
196, 273, 275, 407, 431, 492, 493, 507, 557, 564, 568, 569, 575, 590,
644, 648, 653, 658, 718
DD -- Issue: REAL-NUMBER-TYPE
05-APR-89, Version 4 by Pitman (changes per X3J13)
s2200, 768, chapter7, predicates
DD -- Issue: REDUCE-ARGUMENT-EXTRACTION
Version 3 by Masinter 13-Feb-88
REDUCE-ARGUMENT-EXTRACTION -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]REDUCE-ARGUMENT-EXTRACTION.TXT;1 -- add :key to
reduce and others.
f564, f212
DD -- Issue: REMF-DESTRUCTION-UNSPECIFIED
05-Apr-89, Version 7 by Pitman (typos corrected per X3J13)
315, 566, 572, (461), 581, (216), 568, 569, 460, (479), 692,
453, 336, 596, 658
DD -- Issue: REQUIRE-PATHNAME-DEFAULTS
Version 6 by Pierson 12/9/88, remove *MODULES* as well
Remove PROVIDE, REQUIRE, and *MODULES* from the Common Lisp standard.
sa300, 534, 433, s6100, eventually chapter6, chapter7, packages
DD -- Issue: REST-LIST-ALLOCATION
12-Dec-88, Version 3 by Clinger (delete bogus examples)
Specify that the value of an &REST parameter is permitted, but not required,
to share (top-level) structure with the last argument to APPLY.
s4100
DD -- Issue: RETURN-VALUES-UNSPECIFIED
9-Dec-88, Version 6 by Masinter
Clarify that the return values for the listed constructs are as follows:
171, 326, 574, 682, 335, 484, 485, 603, 690, 691, 696, 218, 329, 598,
366, 190, 561, 598
DD -- Issue: ROOM-DEFAULT-ARGUMENT
Edit history: 12-Sep-88, Version 1 by Pitman
Specify that passing an argument of :DEFAULT is equivalent to passing
no argument to ROOM.
582
** still an outstanding question @ rotatef... on this one. (JonL)
DD -- Issue: SETF-SUB-METHODS
Version 5: Masinter (respond to comments)
This proposal specifies more explicilty the behavior of SETF in the case
of access forms whose sub-forms are permitted to be generalized variable
references [and which thus need to call GET-SETF-METHOD during setf macro
expansion].
599
DD -- Issue: SHADOW-ALREADY-PRESENT
Version 4 Masinter 10-Nov-87
SHADOW-ALREADY-PRESENT -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]SHADOW-ALREADY-PRESENT.TT;1 -- change shadow
to add the symbol even if it is already present.
f602
DD -- Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 by Masinter 14-Nov-87
SHARPSIGN-PLUS-MINUS-PACKAGE -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]SHARPSIGN-PLUS-MINUS-PACKAGE.TXT;1 -- the default
package while reading features is the keyword package.
s3100, f265
DD -- Issue: SPECIAL-TYPE-SHADOWING
Edit history: Version 1, 04-Nov-88 by David Gray
Clarify that if there is a local type declaration for a special
variable, and there is also a global type proclamation for that same
variable, then the value of the variable within the scope of the local
declaration must be a member of the intersection of the two declared
types.
202
DD -- Issue: STANDARD-INPUT-INITIAL-BINDING
Version 8 by Pierson 7/ 8/88, yet more clean up
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as
defined in CLtL. This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.
626, 627, 252, 683, 539, 200, 676
Issue: STEP-ENVIRONMENT
***need v4***
1. Clarify that STEP and TIME evaluate the form in the current environment.
Issue: STREAM-ACCESS
30-Nov-88, version 2 by Masinter
First, add a function to determine whether a stream is "OPEN":
769, 770, 771, 772, 773, 774, 775, 776, chapter6, chapter7, streams,
s2200, 369, 398, 400, 481, 407, 710, 411, 711, 408, 713
DD -- Issue: SUBSEQ-OUT-OF-BOUNDS
29-Mar-88, Version 2 by Steele, in response to Moon's comments
SUBSEQ-OUT-OF-BOUNDS -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]SUBSEQ-OUT-OF-BOUNDS.TXT;1 -- specify what happens
when :start and :end arguments are out of bounds.
f653, f196, f273, f275, f431, f492, f493, f507, f557, f564, 568, f216,
f569, f575, 590, f644, f648, f658, f710, f718
** need new version
Issue: SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
DD -- Issue: SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Masinter
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
202, 939
DD -- Issue: SYMBOL-MACROLET-SEMANTICS
14-Mar-89, Version 6 by Steele
939, 391, 600, 448
DD -- Issue: TAILP-NIL
9-Dec-88, Version 5 by Masinter (clarify EQL)
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
672
DD -- Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2 by Masinter 2-Dec-88
Rewrite the specification so that it is clear that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
694, 502, 554
** need new version
Issue: VARIABLE-LIST-ASYMMETRY
08-Oct-88, Version 3 by Pitman
Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.
DD -- Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (passed June 88?)
Version 5, 7-Jun-88 Masinter (more nits)
713
**************************************************************************
compiler issues follow: these will be included after the completion of
the compiler section (4.2) if they have not already been included.
DD -- Issue: ALLOW-LOCAL-INLINE
30 Dec. 88 V4 by Sandra Loosemore -- suggestions from Pitman
Clarifies use of INLINE proclamation.
s4200
DD -- Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
V8, 31 Dec 1988 Sandra Loosemore
Clarify what the effect of COMPILE-FILE is.
s4200
Issue: COMPILER-DIAGNOSTICS
V10, 22 Mar 1989, Sandra Loosemore (error terminology)
Issue: COMPILER-LET-CONFUSION
V8, 23 Mar 1989, Sandra Loosemore (fix another bug, add
to discussion)
Issue: COMPILER-VERBOSITY
V6, 26 Jan 1989, Sandra Loosemore (remove USE-CONDITIONS)
Issue: CONSTANT-CIRCULAR-COMPILATION:YES
V8, 18 Mar 1989, Sandra Loosemore (changes per Moon, Masinter)
Issue: CONSTANT-COLLAPSING
V6, 22 Mar 1989, Sandra Loosemore (comments from Moon)
Issue: CONSTANT-COMPILABLE-TYPES
03/22/89, V9 by Loosemore (restructure)
DD -- Issue: CONSTANT-MODIFICATION
V2, 12 Dec 1988, Sandra Loosemore
Disallow modification of constants inside QUOTE.
039, 062, 137, 243, 652, 662, 599
Issue: DEFCONSTANT-SPECIAL
V3, 30 Dec 1988, Sandra Loosemore
Issue: DEFINING-MACROS-NON-TOP-LEVEL 315
22-Mar-89, V9 by Sandra Loosemore (add MACROLET stuff)
Issue: EVAL-WHEN-NON-TOP-LEVEL
22-Mar-89, Version 7 by Loosemore (order of processing)
Issue: LOAD-OBJECTS
Version 4, 4-Apr-89, by Pitman (changes per X3J13 Mar 89;
MAKE-LOAD-FORM-USING-SLOTS => MAKE-LOAD-FORM-SAVING-SLOTS)
Issue: LOAD-TIME-EVAL:R**3
11-Mar-89, Version 11 by Loosemore
Issue: MACRO-ENVIRONMENT-EXTENT:DYNAMIC
V3, 13 Mar 1989, Sandra Loosemore (last-minute discussion)
Issue: QUOTE-SEMANTICS:NO-COPYING
V3, 22 Mar 1989, Sandra Loosemore (suggestions from Moon)
Issue: SHARP-COMMA-CONFUSION
V2, 30 Dec 1988, Sandra Loosemore (comments from Pitman)
Remove the #, read macro from the language.
Issue: WITH-COMPILATION-UNIT:NEW-MACRO
13-Mar-89, Version 3 by Loosemore (update discussion)
****************************************************************************
editorial issues: they will either be part of chapter 1, part of the
error terminology, or a policy.
Issue: DEPRECATION-POSITION
9-JAN-89, Version 3 by Chapman
"policy"
Issue: SUBSETTING-POSITION
10-MAR-89, Version 5 by Chapman (added discussion)
"policy"
Issue: EXTENSIONS-POSITION:DOCUMENTATION
10-MAR-89, Version 7 by Chapman (added discussion)
1.7
Issue: UNSOLICITED-MESSAGES
6-APR-89, Version 6 by Chapman (added amendment from 3/89 mtg)
1.7
Issue: ERROR-TERMINOLOGY
14-APR-89, Version 9 by Chapman (added SAFE-CODE clarification
"error terms"
Issue: MACRO-AS-FUNCTION:DISALLOW
6-FEB-89, Version 2 by Chapman
1.7
***take this one out***DD -- APPEND-DOTTED -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]APPEND-DOTTED.TXT;1 -- clarify what happens
when non-last element is a dotted list.
f033,f453
*****************************************************************************
Issues that will probably come up and pass in some form in June:
*****************************************************************************
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
Issue: DYNAMIC-EXTENT-FUNCTION
Edit history: 04-Apr-89, Version 1 by Loosemore
Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
Edit history: 06-Mar-89, Version 1 by Pitman
Issue: HASH-TABLE-SIZE
Edit history: Version 1, 20-Mar-89, by Moon
Issue: LOAD-TRUENAME
11-Apr-89, Version 4 by Pitman (merge Moon's v3 comments)
Issue: PATHNAME-COMPONENT-CASE
22-Mar-89, Version 2 by Moon, update and rewrite
Issue: PATHNAME-COMPONENT-VALUE
Edit history: Version 1, 20-Mar-89, by Moon
Issue: PATHNAME-SUBDIRECTORY-LIST
23-Mar-89, Version 4 by Pitman ([hopefully] just fix typos)
Issue: PATHNAME-SYNTAX-ERROR-TIME
Edit history: 07-Jul-88, Version 1 by Pitman
Issue: PATHNAME-WILD
06-Oct-88, Version 2 by Pitman
Issue: PRETTY-PRINT-INTERFACE
Version 4, 22-Mar-89 by Waters
Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
Edit history: 26-Jan-89, Version 1 by Pitman
Issue: READ-CASE-SENSITIVITY
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Issue: CLOS-MACRO-COMPILATION
V3, 21 Mar 1989, Sandra Loosemore (fix error language)
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
V5, 22 Mar 1989, Sandra Loosemore (fix error language)
Issue: COMPILE-FILE-SYMBOL-HANDLING
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
Issue: COMPILED-FUNCTION-REQUIREMENTS
V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
Issue: CONSTANT-FUNCTION-COMPILATION
Edit History: V1, 22 Mar 1989, Sandra Loosemore (split from issue
CONSTANT-COMPILABLE-TYPES)
Issue: DEFCONSTANT-NOT-WIRED
13 Mar 1989, V6 by Sandra Loosemore (start over)
Issue: MACRO-CACHING
11-Mar-89, Version 2 by Loosemore (add discussion)
Issue: PROCLAIM-ETC-IN-COMPILE-FILE
13 Mar 89, V4 by Sandra Loosemore (discussion)
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
Issue: CONFORMANCE-POSITION
Issue: EXTRA-RETURN-VALUES
∂03-May-89 0428 Quinquevirate-mailer file name/number mapping
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 89 04:28:05 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA17913; Wed, 3 May 89 04:29:05 PDT
Message-Id: <8905031129.AA17913@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA17913; Wed, 3 May 89 04:29:05 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 May 89 07:08
To: quinquevirate@sail.stanford.edu
Subject: file name/number mapping
Where there are names duplicated (NOT numbers, hopefully), the
file with the higher number has superceded the file with the lower
number (for example BREAK-ON-WARNINGS).
F001.STAR
F002.STARVAR
F003.STARSTAR
F004.STARSTARSTAR
F005.PLUS
F006.PLUSVAR
F007.PLUSPLUS
F008.PLUSPLUSPLUS
F009.MINUS
F010.MINUSVAR
F011.SLASH
F012.SLASHVAR
F013.SLASHSLASH
F014.SLASHSLASHSLASH
F015.SLASHEQSIGN
F016.1PLUS
F017.1MINUS
F018.LESSTHAN
F019.LESSTHANEQSIGN
F020.EQSIGN
F021.GTRTHAN
F022.GTRTHANEQSIGN
F023.ABS
F024.ACONS
F025.ACOSH
F026.ACOS
F027.ADJOIN
F028.ADJUST-ARRAY
F029.ADJUSTABLE-ARRAY-P
F030.ALPHA-CHAR-P
F031.ALPHANUMERICP
F032.AND
F033.APPEND
F034.APPLY
F035.APPLYHOOK
F036.APPLYHOOKVAR
F037.APROPOS
F038.APROPOS-LIST
F039.AREF
F040.ARRAY-DIMENSION-LIMIT
F041.ARRAY-DIMENSION
F042.ARRAY-DIMENSIONS
F043.ARRAY-ELEMENT-TYPE
F044.ARRAY-HAS-FILL-POINTER-P
F045.ARRAY-IN-BOUNDS-P
F046.ARRAY-RANK
F047.ARRAY-RANK-LIMIT
F048.ARRAY-ROW-MAJOR-INDEX
F049.ARRAY-TOTAL-SIZE
F050.ARRAY-TOTAL-SIZE-LIMIT
F051.ARRAYP
F052.ASH
F053.ASIN
F054.ASINH
F055.ASSERT
F056.ASSOC
F057.ASSOC-IF
F058.ASSOC-IF-NOT
F059.ATAN
F060.ATANH
F061.ATOM
F062.BIT
F063.BIT-AND
F064.BIT-ANDC1
F065.BIT-ANDC2
F066.BIT-EQV
F067.BIT-IOR
F068.BIT-NAND
F069.BIT-NOR
F070.BIT-NOT
F071.BIT-ORC1
F072.BIT-ORC2
F073.BIT-VECTOR-P
F074.BIT-XOR
F075.BLOCK
F076.BOOLE
F077.BOOLE-1
F078.BOOLE-2
F079.BOOLE-AND
F080.BOOLE-ANDC1
F081.BOOLE-ANDC2
F082.BOOLE-C1
F083.BOOLE-C2
F084.BOOLE-CLR
F085.BOOLE-EQV
F086.BOOLE-IOR
F087.BOOLE-NAND
F088.BOOLE-NOR
F089.BOOLE-ORC1
F090.BOOLE-ORC2
F091.BOOLE-SET
F092.BOOLE-XOR
F093.BOTH-CASE-P
F094.BOUNDP
F095.BREAK
F096.BREAK-ON-WARNINGS
F097.BUTLAST
F098.BYTE
F099.BYTE-POSITION
F100.BYTE-SIZE
F101.CAAAAR
F102.CAAADR
F103.CAAAR
F104.CAADAR
F105.CAADDR
F106.CAADR
F107.CAAR
F108.CADAAR
F109.CADADR
F110.CADAR
F111.CADDAR
F112.CADDDR
F113.CADDR
F114.CADR
F115.CALL-ARGUMENTS-LIMIT
F116.CAR
F117.CASE
F118.CATCH
F119.CCASE
F120.CDAAAR
F121.CDAADR
F122.CDAAR
F123.CDADAR
F124.CDADDR
F125.CDADR
F126.CDAR
F127.CDDAAR
F128.CDDADR
F129.CDDAR
F130.CDDDAR
F131.CDDDDR
F132.CDDDR
F133.CDDR
F134.CDR
F135.CEILING
F136.CERROR
F137.CHAR
F138.CHAR-BIT
F139.CHAR-BITS-LIMIT
F140.CHAR-BITS
F141.CHAR-CODE
F142.CHAR-CODE-LIMIT
F143.CHAR-CONTROL-BIT
F144.CHAR-DOWNCASE
F145.CHAR-EQUAL
F146.CHAR-FONT
F147.CHAR-FONT-LIMIT
F148.CHAR-GREATERP
F149.CHAR-HYPER-BIT
F150.CHAR-INT
F151.CHAR-LESSP
F152.CHAR-META-BIT
F153.CHAR-NAME
F154.CHAR-NOT-EQUAL
F155.CHAR-NOT-GREATERP
F156.CHAR-NOT-LESSP
F157.CHAR-SUPER-BIT
F158.CHAR-UPCASE
F159.CHARSLASHEQSIGN
F160.CHARLESSTHAN
F161.CHARLESSTHANEQSIGN
F162.CHAREQSIGN
F163.CHARGTRTHAN
F164.CHARGTRTHANEQSIGN
F165.CHARACTERP
F166.CHARACTER
F167.CHECK-TYPE
F168.CIS
F169.CLEAR-INPUT
F170.CLEAR-OUTPUT
F171.CLOSE
F172.CLRHASH
F173.CODE-CHAR
F174.COERCE
F175.COMMONP
F176.COMPILE
F177.COMPILE-FILE
F178.COMPILED-FUNCTION-P
F179.COMPILER-LET
F180.COMPLEXP
F181.COMPLEX
F182.CONCATENATE
F183.COND
F184.CONJUGATE
F185.CONS
F186.CONSP
F187.CONSTANTP
F188.COPY-ALIST
F189.COPY-LIST
F190.COPY-READTABLE
F191.COPY-SEQ
F192.COPY-SYMBOL
F193.COPY-TREE
F194.COS
F195.COSH
F196.COUNT
F197.COUNT-IF
F198.COUNT-IF-NOT
F199.CTYPECASE
F200.DEBUG-IO
F201.DECF
F202.DECLARE
F203.DECODE-FLOAT
F204.DECODE-UNIVERSAL-TIME
F205.DEFAULT-PATHNAME-DEFAULTS
F206.DEFCONSTANT
F207.DEFINE-MODIFY-MACRO
F208.DEFINE-SETF-METHOD
F209.DEFMACRO
F210.DEFPARAMETER
F211.DEFSETF
F212.DEFSTRUCT
F213.DEFTYPE
F214.DEFUN
F215.DEFVAR
F216.DELETE
F217.DELETE-DUPLICATES
F218.DELETE-FILE
F219.DELETE-IF
F220.DELETE-IF-NOT
F221.DENOMINATOR
F222.DEPOSIT-FIELD
F223.DESCRIBE
F224.DIGIT-CHAR
F225.DIGIT-CHAR-P
F226.DIRECTORY
F227.DIRECTORY-NAMESTRING
F228.DISASSEMBLE
F229.DO-DOSTAR
F230.DO-ALL-SYMBOLS
F231.DO-EXTERNAL-SYMBOLS
F232.DO-SYMBOLS
F233.DOCUMENTATION
F234.DOLIST
F235.DOTIMES
F236.DOUBLE-FLOAT-EPSILON
F237.DOUBLE-FLOAT-NEGATIVE-EPSILON
F238.DPB
F239.DRIBBLE
F240.ECASE
F241.ED
F242.EIGHTH
F243.ELT
F244.ENCODE-UNIVERSAL-TIME
F245.ENDP
F246.ENOUGH-NAMESTRING
F247.EQ
F248.EQL
F249.EQUALP
F250.EQUAL
F251.ERROR
F252.ERROR-OUTPUT
F253.ETYPECASE
F254.EVAL
F255.EVAL-WHEN
F256.EVALHOOKVAR
F257.EVALHOOK
F258.EVENP
F259.EVERY
F260.EXP
F261.EXPORT
F262.EXPT
F263.FBOUNDP
F264.FCEILING
F265.FEATURES
F266.FFLOOR
F267.FIFTH
F268.FILE-AUTHOR
F269.FILE-LENGTH
F270.FILE-NAMESTRING
F271.FILE-POSITION
F272.FILE-WRITE-DATE
F273.FILL
F274.FILL-POINTER
F275.FIND
F276.FIND-ALL-SYMBOLS
F277.FIND-IF
F278.FIND-IF-NOT
F279.FIND-PACKAGE
F280.FIND-SYMBOL
F281.FINISH-OUTPUT
F282.FIRST
F283.FLET
F284.FLOAT
F285.FLOAT-DIGITS
F286.FLOAT-PRECISION
F287.FLOAT-RADIX
F288.FLOAT-SIGN
F289.FLOATP
F290.FLOOR
F291.FMAKUNBOUND
F292.FORCE-OUTPUT
F293.FORMAT
F294.FOURTH
F295.FRESH-LINE
F296.FROUND
F297.FTRUNCATE
F298.FUNCALL
F299.FUNCTION
F300.FUNCTIONP
F301.GCD
F302.GENSYM
F303.GENTEMP
F304.GET
F305.GET-DECODED-TIME
F306.GET-DISPATCH-MACRO-CHARACTER
F307.GET-INTERNAL-REAL-TIME
F308.GET-INTERNAL-RUN-TIME
F309.GET-MACRO-CHARACTER
F310.GET-OUTPUT-STREAM-STRING
F311.GET-PROPERTIES
F312.GET-SETF-METHOD-MULTIPLE-VALUE
F313.GET-SETF-METHOD
F314.GET-UNIVERSAL-TIME
F315.GETF
F316.GETHASH
F317.GO
F318.GRAPHIC-CHAR-P
F319.HASH-TABLE-COUNT
F320.HASH-TABLE-P
F321.HOST-NAMESTRING
F322.IDENTITY
F323.IF
F324.IMAGPART
F325.IMPORT
F326.IN-PACKAGE
F327.INCF
F328.INPUT-STREAM-P
F329.INSPECT
F330.INT-CHAR
F331.INTEGER-DECODE-FLOAT
F332.INTEGER-LENGTH
F333.INTEGERP
F334.INTERNAL-TIME-UNITS-PER-SECOND
F335.INTERN
F336.INTERSECTION
F337.ISQRT
F338.KEYWORDP
F339.LABELS
F340.LAMBDA-LIST-KEYWORDS
F341.LAMBDA-PARAMETERS-LIMIT
F342.LAST
F343.LCM
F344.LDB
F345.LDB-TEST
F346.LDIFF
F347.LEAST-NEGATIVE-DOUBLE-FLOAT
F348.LEAST-NEGATIVE-LONG-FLOAT
F349.LEAST-NEGATIVE-SHORT-FLOAT
F350.LEAST-NEGATIVE-SINGLE-FLOAT
F351.LEAST-POSITIVE-DOUBLE-FLOAT
F352.LEAST-POSITIVE-LONG-FLOAT
F353.LEAST-POSITIVE-SHORT-FLOAT
F354.LEAST-POSITIVE-SINGLE-FLOAT
F355.LENGTH
F356.LET-LETSTAR
F357.LISP-IMPLEMENTATION-TYPE
F358.LISP-IMPLEMENTATION-VERSION
F359.LIST-LISTSTAR
F360.LIST-ALL-PACKAGES
F361.LIST-LENGTH
F362.LISTEN
F363.LISTP
F364.LOAD
F365.LOAD-VERBOSE
F366.LOCALLY
F367.LOG
F368.LOGANDC1
F369.LOGANDC2
F370.LOGAND
F371.LOGBITP
F372.LOGCOUNT
F373.LOGEQV
F374.LOGIOR
F375.LOGNAND
F376.LOGNOR
F377.LOGNOT
F378.LOGORC1
F379.LOGORC2
F380.LOGTEST
F381.LOGXOR
F382.LONG-FLOAT-EPSILON
F383.LONG-FLOAT-NEGATIVE-EPSILON
F384.LONG-SITE-NAME
F385.LOOP
F386.LOWER-CASE-P
F387.MACHINE-INSTANCE
F388.MACHINE-TYPE
F389.MACHINE-VERSION
F390.MACRO-FUNCTION
F391.MACROEXPAND
F392.MACROEXPAND-1
F393.MACROEXPAND-HOOK
F394.MACROLET
F395.MAKE-ARRAY
F396.MAKE-BROADCAST-STREAM
F397.MAKE-CHAR
F398.MAKE-CONCATENATED-STREAM
F399.MAKE-DISPATCH-MACRO-CHARACTER
F400.MAKE-ECHO-STREAM
F401.MAKE-HASH-TABLE
F402.MAKE-LIST
F403.MAKE-PACKAGE
F404.MAKE-PATHNAME
F405.MAKE-RANDOM-STATE
F406.MAKE-SEQUENCE
F407.MAKE-STRING-INPUT-STREAM
F408.MAKE-STRING-OUTPUT-STREAM
F409.MAKE-STRING
F410.MAKE-SYMBOL
F411.MAKE-SYNONYM-STREAM
F412.MAKE-TWO-WAY-STREAM
F413.MAKUNBOUND
F414.MAP
F415.MAPC
F416.MAPCAN
F417.MAPCAR
F418.MAPCON
F419.MAPHASH
F420.MAPL
F421.MAPLIST
F422.MASK-FIELD
F423.MAX
F424.MEMBER
F425.MEMBER-IF
F426.MEMBER-IF-NOT
F427.MERGE
F428.MERGE-PATHNAMES
F429.MIN
F430.MINUSP
F431.MISMATCH
F432.MOD
F433.MODULES
F434.MOST-NEGATIVE-DOUBLE-FLOAT
F435.MOST-NEGATIVE-FIXNUM
F436.MOST-NEGATIVE-LONG-FLOAT
F437.MOST-NEGATIVE-SHORT-FLOAT
F438.MOST-NEGATIVE-SINGLE-FLOAT
F439.MOST-POSITIVE-DOUBLE-FLOAT
F440.MOST-POSITIVE-FIXNUM
F441.MOST-POSITIVE-LONG-FLOAT
F442.MOST-POSITIVE-SHORT-FLOAT
F443.MOST-POSITIVE-SINGLE-FLOAT
F444.MULTIPLE-VALUE-BIND
F445.MULTIPLE-VALUE-CALL
F446.MULTIPLE-VALUE-LIST
F447.MULTIPLE-VALUE-PROG1
F448.MULTIPLE-VALUE-SETQ
F449.MULTIPLE-VALUES-LIMIT
F450.NAME-CHAR
F451.NAMESTRING
F452.NBUTLAST
F453.NCONC
F454.NIL
F455.NINTERSECTION
F456.NINTH
F457.NOT
F458.NOTANY
F459.NOTEVERY
F460.NRECONC
F461.NREVERSE
F462.NSET-DIFFERENCE
F463.NSET-EXCLUSIVE-OR
F464.NSTRING-CAPITALIZE
F465.NSTRING-DOWNCASE
F466.NSTRING-UPCASE
F467.NSUBLIS
F468.NSUBST
F469.NSUBST-IF
F470.NSUBST-IF-NOT
F471.NSUBSTITUTE
F472.NSUBSTITUTE-IF
F473.NSUBSTITUTE-IF-NOT
F474.NTH
F475.NTHCDR
F476.NULL
F477.NUMBERP
F478.NUMERATOR
F479.NUNION
F480.ODDP
F481.OPEN
F482.OR
F483.OUTPUT-STREAM-P
F484.PACKAGE
F485.PACKAGE-NAME
F486.PACKAGE-NICKNAMES
F487.PACKAGE-SHADOWING-SYMBOLS
F488.PACKAGE-USE-LIST
F489.PACKAGE-USED-BY-LIST
F490.PACKAGEP
F491.PAIRLIS
F492.PARSE-INTEGER
F493.PARSE-NAMESTRING
F494.PATHNAME
F495.PATHNAME-DEVICE
F496.PATHNAME-DIRECTORY
F497.PATHNAME-HOST
F498.PATHNAME-NAME
F499.PATHNAME-TYPE
F500.PATHNAME-VERSION
F501.PATHNAMEP
F502.PEEK-CHAR
F503.PHASE
F504.PI
F505.PLUSP
F506.POP
F507.POSITION
F508.POSITION-IF
F509.POSITION-IF-NOT
F510.PPRINT
F511.PRIN1
F512.PRIN1-TO-STRING
F513.PRINC
F514.PRINC-TO-STRING
F515.PRINT
F516.PRINT-ARRAY
F517.PRINT-BASE
F518.PRINT-CASE
F519.PRINT-CIRCLE
F520.PRINT-ESCAPE
F521.PRINT-GENSYM
F522.PRINT-LENGTH
F523.PRINT-LEVEL
F524.PRINT-PRETTY
F525.PRINT-RADIX
F526.PROBE-FILE
F527.PROCLAIM
F528.PROG
F529.PROGSTAR
F530.PROG1
F531.PROG2
F532.PROGN
F533.PROGV
F534.PROVIDE
F535.PSETF
F536.PSETQ
F537.PUSH
F538.PUSHNEW
F539.QUERY-IO
F540.QUOTE
F541.RANDOM
F542.RANDOM-STATE
F543.RANDOM-STATE-P
F544.RASSOC
F545.RASSOC-IF
F546.RASSOC-IF-NOT
F547.RATIONAL
F548.RATIONALIZE
F549.RATIONALP
F550.READ
F551.READ-BASE
F552.READ-BYTE
F553.READ-CHAR-NO-HANG
F554.READ-CHAR
F555.READ-DEFAULT-FLOAT-FORMAT
F556.READ-DELIMITED-LIST
F557.READ-FROM-STRING
F558.READ-LINE
F559.READ-PRESERVING-WHITESPACE
F560.READ-SUPPRESS
F561.READTABLE
F562.READTABLEP
F563.REALPART
F564.REDUCE
F565.REM
F566.REMF
F567.REMHASH
F568.REMOVE
F569.REMOVE-DUPLICATES
F570.REMOVE-IF
F571.REMOVE-IF-NOT
F572.REMPROP
F573.RENAME-FILE
F574.RENAME-PACKAGE
F575.REPLACE
F576.REQUIRE
F577.REST
F578.RETURN
F579.RETURN-FROM
F580.REVAPPEND
F581.REVERSE
F582.ROOM
F583.ROTATEF
F584.ROUND
F585.RPLACA
F586.RPLACD
F587.SBIT
F588.SCALE-FLOAT
F589.SCHAR
F590.SEARCH
F591.SECOND
F592.SET
F593.SET-CHAR-BIT
F594.SET-DIFFERENCE
F595.SET-DISPATCH-MACRO-CHARACTER
F596.SET-EXCLUSIVE-OR
F597.SET-MACRO-CHARACTER
F598.SET-SYNTAX-FROM-CHAR
F599.SETF
F600.SETQ
F601.SEVENTH
F602.SHADOW
F603.SHADOWING-IMPORT
F604.SHIFTF
F605.SHORT-FLOAT-EPSILON
F606.SHORT-FLOAT-NEGATIVE-EPSILON
F607.SHORT-SITE-NAME
F608.SIGNUM
F609.SIMPLE-BIT-VECTOR-P
F610.SIMPLE-STRING-P
F611.SIMPLE-VECTOR-P
F612.SIN
F613.SINGLE-FLOAT-EPSILON
F614.SINGLE-FLOAT-NEGATIVE-EPSILON
F615.SINH
F616.SIXTH
F617.SLEEP
F618.SOFTWARE-TYPE
F619.SOFTWARE-VERSION
F620.SOME
F621.SORT
F622.SPECIAL-FORM-P
F623.SQRT
F624.STABLE-SORT
F625.STANDARD-CHAR-P
F626.STANDARD-INPUT
F627.STANDARD-OUTPUT
F628.STEP
F629.STREAM-ELEMENT-TYPE
F630.STREAMP
F631.STRING
F632.STRING-CAPITALIZE
F633.STRING-CHAR-P
F634.STRING-DOWNCASE
F635.STRING-EQUAL
F636.STRING-GREATERP
F637.STRING-LEFT-TRIM
F638.STRING-LESSP
F639.STRING-NOT-EQUAL
F640.STRING-NOT-GREATERP
F641.STRING-NOT-LESSP
F642.STRING-RIGHT-TRIM
F643.STRING-TRIM
F644.STRING-UPCASE
F645.STRINGSLASHEQSIGN
F646.STRINGLESSTHANEQSIGN
F647.STRINGLESSTHAN
F648.STRINGEQSIGN
F649.STRINGGTRTHANEQSIGN
F650.STRINGGTRTHAN
F651.STRINGP
F652.SUBLIS
F653.SUBSEQ
F654.SUBSETP
F655.SUBST
F656.SUBST-IF
F657.SUBST-IF-NOT
F658.SUBSTITUTE
F659.SUBSTITUTE-IF
F660.SUBSTITUTE-IF-NOT
F661.SUBTYPEP
F662.SVREF
F663.SXHASH
F664.SYMBOL-FUNCTION
F665.SYMBOL-NAME
F666.SYMBOL-PACKAGE
F667.SYMBOL-PLIST
F668.SYMBOL-VALUE
F669.SYMBOLP
F670.T
F671.TAGBODY
F672.TAILP
F673.TANH
F674.TAN
F675.TENTH
F676.TERMINAL-IO
F677.TERPRI
F678.THE
F679.THIRD
F680.THROW
F681.TIME
F682.TRACE
F683.TRACE-OUTPUT
F684.TREE-EQUAL
F685.TRUENAME
F686.TRUNCATE
F687.TYPE-OF
F688.TYPECASE
F689.TYPEP
F690.UNEXPORT
F691.UNINTERN
F692.UNION
F693.UNLESS
F694.UNREAD-CHAR
F695.UNTRACE
F696.UNUSE-PACKAGE
F697.UNWIND-PROTECT
F698.UPPER-CASE-P
F699.USE-PACKAGE
F700.USER-HOMEDIR-PATHNAME
F701.VALUES
F702.VALUES-LIST
F703.VECTOR
F704.VECTOR-POP
F705.VECTOR-PUSH
F706.VECTOR-PUSH-EXTEND
F707.VECTORP
F708.WARN
F709.WHEN
F710.WITH-INPUT-FROM-STRING
F711.WITH-OPEN-FILE
F712.WITH-OPEN-STREAM
F713.WITH-OUTPUT-TO-STRING
F714.WRITE
F715.WRITE-BYTE
F716.WRITE-CHAR
F717.WRITE-LINE
F718.WRITE-STRING
F719.WRITE-TO-STRING
F720.Y-OR-N-P
F721.YES-OR-NO-P
F722.ZEROP
F750.ROW-MAJOR-AREF
F751.UPGRADED-ARRAY-ELEMENT-TYPE
F752.UPGRADED-COMPLEX-PART-TYPE
F753.DEFPACKAGE
F754.DESCRIBE-OBJECT
F755.DESTRUCTURING-BIND
F756.COMPLEMENT
F757.FUNCTION-LAMBDA-EXPRESSION
F758.FDEFINITION
F759.GENSYM-COUNTER
F760.HASH-TABLE-REHASH-SIZE
F761.HASH-TABLE-REHASH-THRESHOLD
F762.HASH-TABLE-SIZE
F763.HASH-TABLE-TEST
F764.WITH-HASH-TABLE-ITERATOR
F765.WITH-PACKAGE-ITERATOR
F766.NTH-VALUE
F767.DELETE-PACKAGE
F768.REALP
F769.OPEN-STREAM-P
F770.BROADCAST-STREAM-STREAMS
F771.CONCATENATED-STREAM-STREAMS
F772.ECHO-STREAM-INPUT-STREAM
F773.ECHO-STREAM-OUTPUT-STREAM
F774.SYNONYM-STREAM-SYMBOL
F775.TWO-WAY-STREAM-INPUT-STREAM
F800.ABORT
F801.ARITHMETIC-ERROR-OPERANDS
F802.ARITHMETIC-ERROR-OPERATION
F803.ASSERT
F804.BREAK
F805.BREAK-ON-SIGNALS
F806.BREAK-ON-WARNINGS
F807.CCASE
F808.CELL-ERROR-NAME
F809.CERROR
F810.CHECK-TYPE
F811.COMPUTE-RESTARTS
F812.CONTINUE
F813.CTYPECASE
F814.DEBUGGER-HOOK
F815.DEFINE-CONDITION
F816.ECASE
F817.ERROR
F818.ETYPECASE
F819.FILE-ERROR-PATHNAME
F820.FIND-RESTART
F821.HANDLER-BIND
F822.HANDLER-CASE
F823.IGNORE-ERRORS
F824.INVOKE-DEBUGGER
F825.INVOKE-RESTART-INTERACTIVELY
F826.INVOKE-RESTART
F827.MAKE-CONDITION
F828.MUFFLE-WARNING
F829.PACKAGE-ERROR-PACKAGE
F830.RESTART-BIND
F831.RESTART-CASE
F832.RESTART-NAME
F833.SIGNAL
F834.SIMPLE-CONDITION-FORMAT-ARGUMENTS
F835.SIMPLE-CONDITION-FORMAT-STRING
F836.STORE-VALUE
F837.STREAM-ERROR-STREAM
F838.TYPE-ERROR-DATUM
F839.TYPE-ERROR-EXPECTED-TYPE
F840.USE-VALUE
F841.WARN
F842.WITH-SIMPLE-RESTART
F900.ADD-METHOD
F901.CALL-METHOD
F902.CALL-NEXT-METHOD
F903.CHANGE-CLASS
F904.CLASS-NAME
F905.CLASS-OF
F906.COMPUTE-APPLICABLE-METHODS
F907.DEFCLASS
F908.DEFGENERIC
F909.DEFINE-METHOD-COMBINATION
F910.DEFMETHOD
F911.DESCRIBE
F912.DOCUMENTATION
F913.ENSURE-GENERIC-FUNCTION
F914.FIND-CLASS
F915.FIND-METHOD
F916.FUNCTION-KEYWORDS
F917.GENERIC-FLET
F918.GENERIC-FUNCTION
F919.GENERIC-LABELS
F920.INITIALIZE-INSTANCE
F921.INVALID-METHOD-ERROR
F922.MAKE-INSTANCE
F923.MAKE-INSTANCES-OBSOLETE
F924.METHOD-COMBINATION-ERROR
F925.METHOD-QUALIFIERS
F926.NEXT-METHOD-P
F927.NO-APPLICABLE-METHOD
F928.NO-NEXT-METHOD
F929.PRINT-OBJECT
F930.REINITIALIZE-INSTANCE
F931.REMOVE-METHOD
F932.SHARED-INITIALIZE
F933.SLOT-BOUNDP
F934.SLOT-EXISTS-P
F935.SLOT-MAKUNBOUND
F936.SLOT-MISSING
F937.SLOT-UNBOUND
F938.SLOT-VALUE
F939.SYMBOL-MACROLET
F940.UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
F941.UPDATE-INSTANCE-FOR-REDEFINED-CLASS
F942.WITH-ACCESSORS
F943.WITH-ADDED-METHODS
F944.WITH-SLOTS
F945.SETF-CLASS-NAME
F946.SETF-DOCUMENTATION
S1100.SCOPE-PURPOSE-AND-HISTORY
S1200.ORGANIZATION-OF-THE-DOCUMENT
S1300.REFERENCED-PUBLICATIONS
S1400.DEFINITIONS
S1500.COMPLIANCE
S1600.LANGUAGE-EXTENSIONS
S2100.INTRODUCTION
S2200.TYPES
S2300.CLASSES
S2400.SLOTS
S2500.OBJECTS
S3100.CHARACTER-READER
S3200.OBJECT-SYNTAX
S4100.EVALUATION-MODEL
S4200.COMPILATION
S5100.ERRORS
S5200.INPUT-OUTPUT
S5300.INTERFACE-WITH-PROGRAMMING-ENVIRONMENT
S5400.GENERALIZED-REFERENCE
S5500.PREDICATES
S6100.INTRODUCTION
SA100.IMPLEMENTATION-DEFINED-FEATURES
SA200.PORTABILITY-ISSUES
SA300.REMOVED-DEFINED-NAMES
SA400.DEPRECATED-DEFINED-NAMES
∂03-May-89 0531 Quinquevirate-mailer checked out status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 89 05:30:16 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA21008; Wed, 3 May 89 05:31:12 PDT
Message-Id: <8905031231.AA21008@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA21008; Wed, 3 May 89 05:31:12 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 May 89 08:29
To: quinquevirate@sail.stanford.edu
Subject: checked out status
Section Who has Date out
1.1 KC
1.2 KC
1.3 KC
1.4 KC
1.5 KC
1.6 KC
2.1
2.2 KC
3.1 KC
3.2 KC
4.1 KC
4.2
5.1 RPG 4/7/89
5.2 Masinter 4/7/89
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 4/12/89
Glossary KC
CLOS RPG 5/2/89
PREDICATES Masinter 5/3/89
STRINGS Masinter 5/3/89
SEQUENCES Masinter 5/3/89
LISTS Masinter 5/3/89
NUMBERS Masinter 5/3/89
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC
STREAMS KC
FILE KC
CONTROL KC
PROGRAM KC
MISC KC
ERRORS KC
MACROS KC
PACKAGES KC
CHARACTERS KC
EVALUATOR KC
∂03-May-89 1143 Quinquevirate-mailer file name/number mapping
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 3 May 89 11:43:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 589085; 3 May 89 13:54:52 EDT
Date: Wed, 3 May 89 13:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: file name/number mapping
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8905031129.AA17913@decwrl.dec.com>
Message-ID: <19890503175448.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I couldn't figure out what you wanted me to do with this 874 line
message so I just deleted it.
∂03-May-89 1515 Quinquevirate-mailer Re: new cleanups
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 May 89 15:14:08 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 MAY 89 15:08:54 PDT
Date: 3 May 89 15:07 PDT
From: masinter.pa@Xerox.COM
Subject: Re: new cleanups
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Tue, 2 May 89 07:04:46 MDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: masinter.pa@Xerox.COM, quinquevirate@sail.stanford.edu
Message-ID: <890503-150854-10754@Xerox>
Users can rely on EVALHOOK more than they can rely on BREAK. EVALHOOK is
defined as 'a facility that is useful when it makes sense'. Conformal
implementations should be constrained to clearly document whether their
implementation is 'interpreted' or 'compiled', and EVALHOOK's behavior is
well specified: it affects evaluation of 'interpreted' forms and does not
affect the evaluation of 'compiled' forms. It is not true that "... users
can't rely on EVALHOOK doing anything meaningful." It is true that the
behavior of EVALHOOK can vary, in certain well constrained ways, from one
implementation to the next.
∂05-May-89 1908 Quinquevirate-mailer checked out status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 May 89 19:08:10 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA24368; Fri, 5 May 89 13:54:45 PDT
Message-Id: <8905052054.AA24368@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA24368; Fri, 5 May 89 13:54:45 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 5 May 89 16:51
To: quinquevirate@sail.stanford.edu
Subject: checked out status
Section Who has Date out
1.1 RPG 5/5/89
1.2 KC
1.3 KC
1.4 KC
1.5 KC
1.6 KC
2.1 KC
2.2 Moon 5/5/89
2.3 RPG 5/5/89
2.4 RPG 5/5/89
2.5 RPG 5/5/89
3.1 Masinter 5/5/89
3.2 Masinter 5/5/89
3.3 Masinter 5/5/89
3.4 Masinter 5/5/89
4.1 Moon 5/5/89
4.2 KC
5.1 RPG 4/7/89
5.2 Masinter 4/7/89
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 5/5/89
Glossary KC
CLOS RPG 5/2/89
PREDICATES Masinter 5/3/89
STRINGS Masinter 5/3/89
SEQUENCES Masinter 5/3/89
LISTS Masinter 5/3/89
NUMBERS Masinter 5/3/89
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/89
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC
STREAMS KC
FILE KC
CONTROL KC
PROGRAM KC
MISC KC
ERRORS Moon 5/4/89
MACROS Moon 5/4/89
PACKAGES Moon 5/4/89
CHARACTERS Moon 5/4/89
EVALUATOR Moon 5/4/89
∂08-May-89 1430 Quinquevirate-mailer answers to your questions
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 8 May 89 14:30:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 591736; 8 May 89 17:30:35 EDT
Date: Mon, 8 May 89 17:30 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: answers to your questions
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8905052001.AA21503@decwrl.dec.com>
Supersedes: <19890508210023.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19890508211636.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Please disregard the earlier version of this message.
I was interrupted while composing it and I forgot to include
one paragraph (about subclass) that I had intended to include.
This time I spelled the name of the mailing list right
Message-ID: <19890508213041.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I decided I better CC these answers to quinqevirate as an extra check
on my accuracy.
Date: 5 May 89 15:52
From: chapman%aitg.DEC@decwrl.dec.com
Following are some further questions on 2.2, the 4.1 source file
has more questions (preceded by "***").
>Subj: comments on comments on section 2.2
> >p.2-32ff: the many type specifiers added by CLOS are missing, including
> >EQL, the new built-in types like STANDARD-OBJECT and GENERIC-FUNCTION,
> >and the ability to use a class object as a type-specifier.
> I will need some help figuring out how the CLOS types fit here. I had
> planned to generate a clean-up about this and the Condition System
> types after Gregor(?) and KMP help me construct this correctly. Maybe
> it's straightforward, but when I started to do it on my own I ran into
> too many questions.
>
>It shouldn't be necessary to make any decisions, but you may need some
>help decoding the existing documents. I'll be happy to answer any questions
>you have. I don't think a Cleanup should be necessary, as the types have
>already been put into the language by acceptance of earlier documents.
>All we have to do is gather the existing information into a single place
>and put it into a uniform format. I believe none of the CLOS and Condition
>type specifiers take arguments, which makes things simpler.
1. Where can I find the type hierarchy for standard-object, standard-class,
built-in-class, and standard-object?
Here's some material from a draft of chapter 3. This much I believe.
STRUCTURE-OBJECT, STANDARD-OBJECT, GENERIC-FUNCTION, METHOD,
METHOD-COMBINATION, and CLASS are disjoint and each has superclass T.
STANDARD-CLASS, STRUCTURE-CLASS, BUILT-IN-CLASS,
STANDARD-GENERIC-FUNCTION, and STANDARD-METHOD are disjoint and have
superclass CLASS, CLASS, CLASS, GENERIC-FUNCTION, and METHOD
respectively. No exhaustive partitions here. Those are all the classes
I could find in 88-002R; chapter 3 adds some more but we can forget
about them for now.
I don't know why STRUCTURE-OBJECT isn't named STRUCTURE (the name
Symbolics Genera uses). The symbol STRUCTURE already exists in
CLtL Common Lisp (as a word used by the DOCUMENTATION function),
so it seems like the appropriate word.
2. Which classes are actually defined be the CLOS chapters we accepted and
which ones are part of Chapter 3? Are we including some info from Chapter 3
to make the parts we accepted make more sense?
See above.
This doesn't settle all the chapter 2 versus chapter 3 questions, e.g. what
good is ADD-METHOD without chapter 3. I don't want to think about those now.
3. What is the supertype of types RESTART and CONDITION (t, I assume)?
In most implementations, it will probably really be STANDARD-OBJECT, but I
guess the spec should only say T; similar to PATHNAME, RESTART and CONDITION
should be implementable as builtin, structure, or standard class at the
implementor's discretion.
What is the
relationship of the condition system data types to each other (disjoint,
exhaustive partition, ...)?
CONDITION and RESTART, like PATHNAME, are disjoint with everything else,
and with each other. The subtypes of CONDITION have defined relationships
in the condition system document, if I remember correctly.
>p.2-5 second bullet from the bottom: This extends a CLtL comment about
>DEFSTRUCT to DEFCLASS. However, it does not work for DEFCLASS because
>of multiple superclasses. Two classes A and B can have a common subclass
>C, even though A is not a superclass of B and B is not a superclass of A.
>In this case A and B are not disjoint. What you want to say instead is
>that the type relations explicitly created by specifying superclasses
>are the only type relations, or words to that effect.
How about these words:
"Any two {\word classes\/} created by {\function defclass\/}
are related only by
the type relations explicitly created by the {\word superclasses\/} specified
during class creation."
>Okay except I would change "by the type relations explicitly created by"
>to "according to". But maybe this would be better: "Any two {\word
>classes\/} created by {\function defclass\/} are {\word disjoint}
>unless they have a common {\word superclass}." [That assumes that
>our definition of superclass says every class is a superclass of
>itself, which I think is the case, but did not check.]
CLOS (and now section 2.3) says "A class is considered neither a
superclass nor a subclass of itself." So I used "according to".
You lost the context of this remark. I've restored it above, since I
fortunately hadn't gotten around to deleting the mail yet. The wording
you chose is not wrong, but I still think it's a pity we don't have a
term that includes a class as well as its superclasses, so that we can
use the much more explicit wording I suggested. The Flavors word for
this is "component". Even without such a term, I think we could say:
"Any two {\word classes\/} created by {\function defclass\/} are {\word
disjoint} unless they have a common {\word superclass} or one {\word
class} is a {\word superclass} of the other."
Also I think it may be perceived as odd that a type is a subtype and
a supertype of itself (CLtL p.72), but a class is not a subclass nor
a superclass of itself. We can't really change the nomenclature for
types, since it derives directly from the mathematics of sets. I'm
not sure what would be the impact of changing the nomenclature for
classes so that what is now "subclass" would become "proper subclass",
and what is now "superclass" would become "proper superclass". This
would (clearly) not affect "direct subclass" and "direct superclass".
>Now somewhere in 6.1: The reference to APL is questionable, does this mean
>we are incorporating some specific standard by reference (then we should
>give its exact name), or is it just a general remark?
I cited the whole reference this time.
It still doesn't tell me how to order a copy, or is that in a bibliography
elsewhere?
I'll let Guy Steele be the arbiter on this one, but I'm not sure that we want to
just refer to another standard instead of giving the branch cut rules explicitly.
There is too much room for ambiguity or mistakes in mapping between APL and Lisp.
Maybe the branch cut rules are given explicitly, but I haven't been able to find
them. After mentioning the APL document, section 6.1 goes off to talk about
something unrelated.
Section 4.1:
[If an operator symbol doesn't name a function, special form, or macro]
An error of type {\datatype undefined-function\/} might be signalled.
*** I have recorded that the issue UNDEFINED-VARIABLES-AND-FUNCTIONS
has been withdrawn. So I guess we can't adopt its contents, but what
about ``might'' in place of ``should''?
My notes say it's deferred to the June meeting to fix the CLOS slot
part, not withdrawn. That's independent of the function part, and I
think "should" would be best here (as UNDEFINED-VARIABLES-AND-FUNCTIONS
proposes). Can we just change it to "should" or do we have to go
through the cleanup committee?
\itemitem{{\bf Apply:\/} returns the result of the evaluation of the last form
in the lambda body}
*** Moon's comment is that {\function apply\/} is also referenced for
named functions. What to do here?***
Following is the algorithm for {\bf apply\/}.
\beginlist
\itemitem{1.} Find all declarations.
\itemitem{2.} Create new dynamic and lexical contexts.
*** David, please suggest a fix for this.***
\itemitem{3.}{\bf Evaluate forms\/} in the lambda body in the lexical and
dynamic contexts.
Well, I think APPLY is a way of getting some arguments to a function,
and shouldn't say anything about what happens inside the function.
Thus parameter matching, declarations, environments ("contexts"), and
forms in the body shouldn't be mentioned in connection with APPLY.
Maybe APPLY is just completely the wrong word here, and APPLY-LAMBDA
is the word JAR should have used.
The stuff listed here under APPLY correctly belongs under a description
of "calling a lambda", something that both APPLY and FUNCALL do.
Except, we don't call lambdas, we call functions, and lambdas aren't
functions. I couldn't find anything in section 4.1 that was clear about
this, although I was hampered by only looking at TeX source. Thus I
couldn't find the right name for this. What you are trying to describe is
the semantics of calling a user defined function, regardless of whether
that function is defined with DEFUN, FLET, or LAMBDA, and independent of
whether the semantics are implemented by an interpreter or a compiler
(thus independent of whether all the actions are happening at the time
the function is called, or some happened ahead of time). That's all the
help I can offer right now, I sure hope it's enough.
BTW section 4.1 still appears to suffer from saying everything twice,
although it's hard to be sure when reading TeX source. I guess that's
the import of
*** David, please suggest where you want this information to go***
What I want is not for the text attached to that to be moved someplace
else, but to merge or eliminate the duplicated descriptions. For
example, \beginsubsubsection{Symbols as Forms} is about the same topic
as \itemitem{{\bf Variable evaluation:}, and each of them says something
about that topic that the other one fails to say. The two pieces of
text need to be combined and cast into a consistent style, without losing
any of the contained information. Similarly for evaluation of the other
kinds of forms. I don't think I can do this rewriting myself.
∂11-May-89 0725 Quinquevirate-mailer responses to your answers]
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 11 May 89 07:25:42 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA28207; Thu, 11 May 89 07:26:49 PDT
Message-Id: <8905111426.AA28207@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA28207; Thu, 11 May 89 07:26:49 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 11 May 89 10:16
To: @MOON@decwrl.dec.com, quinquevirate@sail.stanford.edu
Subject: responses to your answers]
> >Now somewhere in 6.1: The reference to APL is questionable, does this mean
> >we are incorporating some specific standard by reference (then we should
> >give its exact name), or is it just a general remark?
> I cited the whole reference this time.
>It still doesn't tell me how to order a copy, or is that in a bibliography
>elsewhere?
I put the reference to the book in section 1.3 and cited that book in
place of the acronym.
>I'll let Guy Steele be the arbiter on this one, but I'm not sure that we want to
>just refer to another standard instead of giving the branch cut rules explicitly.
>There is too much room for ambiguity or mistakes in mapping between APL and Lisp.
>Maybe the branch cut rules are given explicitly, but I haven't been able to find
>them. After mentioning the APL document, section 6.1 goes off to talk about
>something unrelated.
The branch cut rules that were in CLtL are located with the descriptions
of the functions to which they apply. Is that organization sensible? Are
there more branch cut rules in the reference that should be explicitly
stated in the standard?
>Section 4.1:
>
> [If an operator symbol doesn't name a function, special form, or macro]
> An error of type {\datatype undefined-function\/} might be signalled.
> *** I have recorded that the issue UNDEFINED-VARIABLES-AND-FUNCTIONS
> has been withdrawn. So I guess we can't adopt its contents, but what
> about ``might'' in place of ``should''?
>
>My notes say it's deferred to the June meeting to fix the CLOS slot
>part, not withdrawn. That's independent of the function part, and I
>think "should" would be best here (as UNDEFINED-VARIABLES-AND-FUNCTIONS
>proposes). Can we just change it to "should" or do we have to go
>through the cleanup committee?
Seems like `should' was a critical part of this proposal. But we could
assume this will pass and use `should' here, then take it out if it doesn't?
∂15-May-89 0342 Quinquevirate-mailer Compiler section (4.2)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 May 89 03:41:52 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA24115; Mon, 15 May 89 03:42:45 PDT
Message-Id: <8905151042.AA24115@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA24115; Mon, 15 May 89 03:42:45 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 May 89 06:40
To: quinquevirate@sail.stanford.edu
Subject: Compiler section (4.2)
This section was written by Sandra and reviewed by RPG. Any other comments
before I begin working on it?
kathy
[rpg: Comments look like this.]
Introduction
============
The compiler is a utility that translates programs into an
implementation-dependent form that can be represented and/or executed
more efficiently. The nature of the processing performed during
compilation is discussed in the "Compilation Semantics" section below.
This is followed by a discussion of the behavior of COMPILE-FILE and
the interface between COMPILE-FILE and LOAD.
[rpg:
The compiler is a utility that may translate programs into an
implementation-dependent form that might be represented or executed
more efficiently. The nature of the processing performed during
compilation is discussed in the "Compilation Semantics" section below.
This is followed by a discussion of the behavior of COMPILE-FILE and
the interface between COMPILE-FILE and LOAD.
]
% References:
% CLtL page 143 (next to last paragraph)
% CLtL page 321 (second paragraph)
[rpg: CLtL page 438]
The functions COMPILE and COMPILE-FILE are used to explicitly force
[rpg: yuck] compilation to take place. It is permissible for
conforming implementations to also perform implicit compilation during
ordinary evaluation. While the evaluator is typically implemented as
an interpreter that traverses the given form recursively, performing
each step of the computation as it goes, a permissible alternate
approach is for the evaluator first to completely compile the form
into machine-executable code and then invoke the resulting code.
Various mixed strategies are also possible. All of these approaches
should produce the same results when executing a correct program, but
may produce different results for incorrect programs.
[rpg: This should say that execution of programs can be accomplished
by a variety of means ranging from direct interpretation of the list
structure representing a program through compilation to machine code,
and that the designer of an interpreter (evaluator?) can select any
of these strategies, and the designer of the compiler should select
any strategy that generally results in code that is no slower or no
bigger and which satisfies the constraints just below.]
% This paragraph should really conclude with a stronger statement that
% conforming programs must be structured so they will work if implicit
% compilation does take place, but CLtL doesn't come right out and say
% that, and we have never voted on any issue to say that either.
Compilation Semantics
=====================
% References:
% Issue COMPILE-ENVIRONMENT-CONSISTENCY [pending]
% Issue COMPILED-FUNCTION-REQUIREMENTS [pending]
% The material in this section will have to be updated to reflect further
% changes to these issues.
Conceptually, compilation can be viewed as a process which traverses a
program, performs certain kinds of syntactic and semantic analysis
using information (such as proclamations and macro definitions)
present in the compile time environment, and produces a modified
program. As a minimum, the compiler must perform the following
actions:
- All macro calls appearing lexically within the code being compiled
must be expanded at compile time and will not be expanded again at
run time. The process of compilation effectively turns MACROLET
and SYMBOL-MACROLET constructs int PROGNs, with all calls to the local
macros in the body replaced by their expansions.
The compiler must treat any form that is a list beginning with a
symbol that does not name a macro or special form as a function call.
(This implies that SETF methods must also be available at compile time.)
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within the
code being compiled are to be treated as lexical or special. The
compiler must treat any binding of a variable that has not been
declared or proclaimed to be SPECIAL as a lexical binding.
- The compiler must process EVAL-WHEN forms that appear lexically within
the program being compiled. Effectively, the compiler must replace
the EVAL-WHEN form with either a PROGN containing the body forms, or
a constant NIL.
- The compiler must process LOAD-TIME-VALUE forms that appear lexically
within the program being compiled. In the case of COMPILE, evaluation
of the LOAD-TIME-VALUE form happens at compile time and the resulting
value is treated as a literal constant at run time. In the case of
COMPILE-FILE, the compiler must arrange for evaluation of the form
to take place at load time.
In addition, the compiler is permitted to incorporate the following
kinds of information into the code it produces, if the information is
present in the compile time environment and is referenced within the
code being compiled. Except where some other behavior is explicitly
stated, when the compile time and run time definitions are different,
it is unspecified which will prevail within the compiled code. It is
also permissible for implementations to signal an error at run time to
complain about the discrepancy. [rpg: Diction.] In all cases, the
absence of the information at compile time is not an error, [rpg:
terminology] but its presence may enable the compiler to generate more
efficient code.
[rpg: There is a complicated issue: Can the compiler assume that the
resulting code in a compile-file situation will be run in the same
Lisp? The same implementation? The same computer? The same type of
computer?
I suggest that we say that the semantics we discuss presumes that the
compiler can assume that when doing compile-file that the resulting
code will be loaded into a fresh copy of the same Lisp.]
- The compiler may assume that functions that are defined and
declared or proclaimed INLINE in the compile time environment will
retain the same definitions at run time.
- The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
[rpg: the interpreter can assume the same thing, right? That is, a
valid Common Lisp has be one in all code is compile-filed by a
separate program and loaded and executed in the apparent Common Lisp
image.]
- COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at run time.
[rpg: the interpreter can assume the same thing, right?]
- The compiler may assume that the argument syntax and number of return
values for all built-in Common Lisp functions will not change. In
addition, the compiler may treat all built-in Common Lisp functions
as if they had been proclaimed INLINE.
[rpg: the interpreter can assume the same thing, right? This follows from
LISP-SYMBOL-REDEFINITION.]
- The compiler may assume that the argument syntax and number of return
values for all functions with FTYPE information available at
compile time will remain the same at run time.
% Reference: CLtL page 69
- The compiler may assume that symbolic constants that have been
defined with DEFCONSTANT in the compile time environment will retain
the same value at run time as at compile time. The compiler may replace
references to the name of the constant with the value of the constant,
provided that such "copies" are EQL to the object that is the
actual value of the constant.
% The following paragraph from issue COMPILE-ENVIRONMENT-CONSISTENCY
% seems likely to change:
- The compiler can assume that type definitions made with DEFTYPE
or DEFSTRUCT in the compile time environment will retain the same
definition in the run time environment. It may also assume that
a class defined by DEFCLASS in the compile time environment will
be defined in the run time environment in such a way as to have
the same superclasses and metaclass. [rpg: compatible metaclass?]
[rpg: This is a little curious. Is this talking only about this sort of case:
(defclass c ...)
(compile-file <something using c>)
or is it trying to cover the case of
(compile-file <...(declass c ...) ... something using c>)
]
This implies that
subtype/supertype relationships of type specifiers will not
change between compile time and run time. (Note that it is not
an error [rpg: terminology?] for an unknown type to appear in a
declaration at
compile time, although it is reasonable for the compiler to
emit a warning in such a case.)
% Ref: CLtL page 153
- The compiler may assume that if type declarations are present
in the compile time environment, the corresponding variables and
functions present in the run time environment will actually be of
those types; otherwise, the run time behavior of the program is
undefined.
The compiler *must not* make any additional assumptions about
consistency between the compile time and run time environments. In
particular:
- The compiler may not assume that functions that are defined
in the compile time environment will retain the either the
same definition or the same signature at run time, except in the
situations explicitly listed above.
- The compiler may not signal an error if it sees a call to a
function that is not defined at compile time, since that function
may be provided at run time.
File Compilation
================
The function COMPILE-FILE performs compilation processing (described
in the previous section) on forms appearing in a file, producing an
output file which may then be loaded with LOAD.
Normally, the top-level forms appearing in a file compiled with
COMPILE-FILE are executed only when the resulting compiled file is
loaded, and not when the file is compiled. However, it often happens
that some forms in the file must be evaluated at compile time in order
for the remainder of the file to be read and compiled correctly; for
example, forms that change the values of *PACKAGE* or *READTABLE* and
macro definitions. In such cases, the distinction between processing
that is performed at compile time and processing that is performed at
load time becomes important.
The special form EVAL-WHEN can be used to give explicit control over
the time at which evaluation of a top-level form takes place, allowing
forms to be executed at compile time, load time, or both. The
behavior of this construct may be more precisely understood in terms
of a model of how COMPILE-FILE processes forms in a file to be
compiled.
Successive forms are read from the file by the file compiler [rpg:
COMPILE-FILE] using READ. These top-level forms are normally processed
in what we call `not-compile-time' mode; in this mode, the file
compiler arranges for forms to be evaluated only at load time and not
at compile time. There is one other mode, called `compile-time-too'
mode, in which forms are evaluated both at compile and load times.
[rpg: what is the file compiler? The thing that compile-file causes to
run?
Also, isn't this requirement that COMPILE-FILE to use READ new? I don't
see why it's required. I suggest removing it.]
Processing of top-level forms in the file compiler works as follows:
* If the form is a macro call, it is expanded and the result is
processed as a top-level form in the same processing mode
(compile-time-too or not-compile-time).
* If the form is a PROGN form, each of its body forms is
sequentially processed as top-level forms in the same processing
mode.
* If the form is a LOCALLY, MACROLET, or SYMBOL-MACROLET,
the file compiler makes the appropriate bindings and recursively
processes the body forms as an implicit top-level PROGN with those
bindings in effect, in the same processing mode. (Note that this
implies that the lexical environment in which top-level forms are
processed is not necessarily the null lexical environment.)
* If the form is an EVAL-WHEN form, it is handled according to
the following table:
:COMPILE- :LOAD- :EXECUTE compile-time-too Action
TOPLEVEL TOPLEVEL
Yes Yes -- -- Process body in compile-time-too mode
No Yes Yes Yes Process body in compile-time-too mode
No Yes Yes No Process body in not-compile-time mode
No Yes No -- Process body in not-compile-time mode
Yes No -- -- Evaluate body
No No Yes Yes Evaluate body
No No Yes No do nothing
No No No -- do nothing
"Process body" means to process the body (using the procedure
outlined in this subsection) as an implicit top-level PROGN.
"Evaluate body" means to evaluate the body forms as an implicit
PROGN in the dynamic execution context of the compiler and in the
lexical environment in which the EVAL-WHEN appears.
* Otherwise, the form is a top-level form that is not one of the
special cases. If in compile-time-too mode, the compiler first
evaluates the form and then performs normal compiler processing
on it. If in not-compile-time mode, only normal compiler
processing is performed. Any subforms are treated as non-top-level
forms.
Note that top-level forms are processed in the order in which they
textually appear in the file, and that each top-level form read by the
compiler is processed before the next is read. However, the order of
processing (including, in particular, macro expansion) of subforms
that are not top-level forms is unspecified.
EVAL-WHEN forms cause compile time evaluation only at top-level. In
non-top-level locations, both the :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL
situations are ignored and only the :EXECUTE situation is considered.
The following macros make definitions that are typically used during
compilation and are defined to make those definitions available at
both compile time and run time when calls to those macros appear in a
file being compiled. As with EVAL-WHEN, these compile time
side-effects happen only when the defining macros appear at top-level.
% The specific details of the compile time side effects should go under
% the description of the macro in chapters 6 & 7.
DEFTYPE
DEFMACRO
DEFINE-MODIFY-MACRO
DEFVAR
DEFPARAMETER
DEFCONSTANT
DEFSETF
DEFINE-SETF-METHOD
DEFSTRUCT
DEFINE-CONDITION
DEFPACKAGE
IN-PACKAGE
% These depend on the outcome of issue CLOS-MACRO-COMPILATION
DEFCLASS
DEFGENERIC
DEFMETHOD
DEFINE-METHOD-COMBINATION
% This depends on the outcome of issue PROCLAIM-ETC-IN-COMPILE-FILE
DEFPROCLAIM
The compile time behavior of these macros can be understood as if
their expansions effectively include (EVAL-WHEN (:COMPILE-TOPLEVEL)
...) forms. It is not required that the compile time definition be
made in the same manner as if the defining macro had been evaluated
directly. In particular, the information stored by the defining
macros at compile time may or may not be available to the evaluator
(either during or after compilation), or during subsequent calls to
COMPILE or COMPILE-FILE. If the definition must be visible during
compile time evaluation, it should be placed within an explicit
(EVAL-WHEN (:COMPILE-TOPLEVEL) ...) to ensure that it will be fully
defined at compile time.
Wrong: (defmacro foo (x) `(car ,x))
(eval-when (:execute :compile-toplevel :load-toplevel)
(print (foo '(a b c))))
Right: (eval-when (:execute :compile-toplevel :load-toplevel)
(defmacro foo (x) `(car ,x))
(print (foo '(a b c))))
Compiler/Loader Interface
=========================
% Reference: Issue QUOTE-SEMANTICS
The functions EVAL and COMPILE always ensure that constants referenced
within the resulting interpreted or compiled code objects are EQL to
the corresponding objects in the source code. COMPILE-FILE, on the
other hand, must produce an output file which contains instructions
[rpg: to] tell the loader how to reconstruct the objects appearing in
the source code when the compiled file is loaded.
[rpg: I prefer this, because the objects may not be *re*constructed since
they might not have been constructed in the first place. Also, ``instructions''
might never appear, only some collaboration need be implied:
COMPILE-FILE, on the other hand, must produce an output file which
when loaded with LOAD constructs the objects defined by the source
code.]
The EQL relationship is not well-defined in this case, since the
compiled file may be loaded into a different Lisp image than the one
that it was compiled in. This section defines a notion of "similarity
as constants" which relates objects in the the compile time
environment to the corresponding objects in the load time environment.
The constraints on constants described in this subsection apply only
to COMPILE-FILE; implementations are not permitted to copy or coalesce
constants appearing in code processed by EVAL or COMPILE.
Terminology
-----------
% Reference: Issue CONSTANT-COMPILABLE-TYPES
The following terminology is used in this section.
The term "constant" refers to a quoted or self-evaluating constant
or an object that is a substructure of such a constant, not a named
(DEFCONSTANT) constant. [rpg: ``self-evaluating means....'']
The term "source code" is used to refer to the objects constructed
when COMPILE-FILE calls READ, and additional objects constructed by
macroexpansion during COMPILE-FILE.
[rpg: I think the source code is whatever the representation is in
whatever a file is. I think this use of READ as a semantic crutch is
unnecessary.]
The term "compiled code" is used to refer to objects constructed by
LOAD.
[rpg: so a floating-point number constructed by LOAD is ``compiled
code''?]
The term "coalesce" is defined as follows. Suppose A and B are two
objects used as quoted constants in the source code, and that A' and
B' are the corresponding objects in the compiled code. If A' and B'
are EQL but A and B were not EQL, then we say that A and B have been
coalesced by the compiler.
[rpg: here is a first pass at changing this wording to avoid READ:
The term "coalesce" is defined as follows. Suppose A and B are two
objects defined as quoted constants in the source code, and that A'
and B' are the corresponding objects in the compiled code. If A' and
B' are EQL but A and B were not defined to be EQL, then we say that A
and B have been coalesced by the compiler.]
What may appear as a constant
-----------------------------
An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original.
The notion of "similarity as a constant" is not well-defined on all
data types. Objects of these types may not portably appear as
constants in code processed with COMPILE-FILE. Conforming
implementations are required to handle such objects either by having
the compiler and/or loader reconstruct an equivalent copy of the
object in some implementation-specific manner; or by having the
compiler signal an error.
For some aggregate data types, being similar as constants is defined
recursively. We say that an object of these types has certain "basic
attributes", and to be similar as a constant to another object, the
values of the corresponding attributes of the two objects must also be
similar as constants.
This kind of definition has problems with any circular or "infinitely
recursive" object such as a list that is an element of itself. We use
the idea of depth-limited comparison, and say that two objects are
similar as constants if they are similar at all finite levels. This
idea is implicit in the definitions below, and applies in all the
places where attributes of two objects are required to be similar as
constants.
[rpg: Hm, this comment can be got around.]
% Reference: issue CONSTANT-CIRCULAR-COMPILATION
Such circular objects may legitimately appear as constants to be
compiled. More generally, if two constants appearing in the source code
for a single file processed with COMPILE-FILE are EQL, the corresponding
constants in the compiled code must also be EQL.
% Reference: issue CONSTANT-COLLAPSING
However, the converse of this relationship need not be true; if two
objects are EQL in the compiled code, that does not always imply that
the corresponding objects in the source code were EQL. This is
because COMPILE-FILE is permitted to coalesce constants appearing in
the source code if and only if they are similar as constants, except if
the objects involved are of type SYMBOL, PACKAGE, STRUCTURE, or
STANDARD-OBJECT. Objects of these types are never coalesced.
Similarity as constants
-----------------------
Two objects are defined to be "similar as a constant" if and only if
they are both of one of the [rpg: same type from the list of] types
listed below and satisfy the additional requirements listed for that
type.
Number
Two numbers are similar as constants if they are of the same type
and represent the same mathematical value.
Character
Two characters are similar as constants if they both represent
the same character.
% Note that this definition has to depend on the results of the
% Character Set proposals. The intent is that this be compatible with
% how EQL is defined on characters.
Symbol
% Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
% and loader handle interned symbols.
An uninterned symbol in the source code is similar as a constant
to an uninterned symbol in the compiled code if their print names
are similar as constants.
Package
A package in the source code is similar as a constant to a package in
the compiled code if their names are similar as constants. Note that
the loader finds the corresponding package object as if by calling
FIND-PACKAGE with the package name as an argument. An error is
signalled if no package of that name exists at load time.
Random-state
Let us say that two random-states are functionally equivalent if
applying RANDOM to them repeatedly always produces the same
pseudo-random numbers in the same order.
Two random-states are similar as constants if and only if copies of
them made via MAKE-RANDOM-STATE are functionally equivalent.
Note that a constant random-state object cannot be used as the "state"
argument to the function RANDOM (because RANDOM side-effects this
data structure).
Cons
Two conses are similar as constants if the values of their respective
CAR and CDR attributes are similar as constants.
Array
Two arrays are similar as constants if the corresponding values each
of the following attributes are similar as constants:
For 1-dimensional arrays:
LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all valid indices.
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all valid indices.
In addition, if the array in the source code is a SIMPLE-ARRAY, then
the corresponding array in the compiled code must also be a
SIMPLE-ARRAY. If the array in the source code is displaced, has a
fill pointer, or is adjustable, the corresponding array in the
compiled code is permitted to lack any or all of these qualities.
[rpg: hm]
Hash Table
Two hash tables are similar as constants if they meet the following
three requirements:
(1) They both have the same test (e.g., they are both EQL hash tables).
(2) There is a unique one-to-one correspondence between the keys of
the two tables, such that the corresponding keys are similar as
constants.
(3) For all keys, the values associated with two corresponding keys
are similar as constants.
If there is more than one possible one-to-one correspondence between
the keys of the two tables, the results are unspecified. A conforming
program cannot use such a table as a constant.
[rpg: So, compilers can only be heuristic in such cases, no?]
Pathname
Two pathnames are similar as constants if all corresponding pathname
components are similar as constants.
Stream, Readtable, Method
Objects of these types are not supported in compiled constants.
Function
% Issue CONSTANT-FUNCTION-COMPILATION specifies how the compiler and
% loader handle constant functions.
Structure, Standard-object
% Reference: issue LOAD-OBJECTS
Objects of type structure and standard-object may appear in compiled
constants if there is an appropriate MAKE-LOAD-FORM method defined
for that type.
COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
a constant or as a self-evaluating form, if the object's metaclass is
STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
subclass of BUILT-IN-CLASS), or any of a possibly-empty
implementation-defined list of other metaclasses. COMPILE-FILE will
only call MAKE-LOAD-FORM once for any given object (compared with EQ)
within a single file.
Condition
% This somehow got overlooked. Are they handled under LOAD-OBJECTS?
[rpg: Yes, since they are instances of classes.]
Compile Time Error Handling
===========================
% Reference: Issue COMPILER-DIAGNOSTICS
% The STYLE-WARNING condition needs to be integrated into the section
% describing the hierarchy of condition types.
Errors and warnings may be issued within COMPILE or COMPILE-FILE.
This includes both arbitrary errors which may occur due to
compile-time processing of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) forms
or macro expansion, and conditions signalled by the compiler itself.
Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation with undefined consequences or that would cause
an error to be signalled would result at runtime.
[rpg: But this is not to be construed as an escape clause that allows
an implementation to not warn when it is required. This attempts to
only talk about how the warning is issued, right?]
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
The compiler is permitted to issue warnings about matters of
programming style as conditions of type STYLE-WARNING. Although
STYLE-WARNINGs -may- be signalled in these situations, no
implementation is -required- to do so. However, if an
implementation does choose to signal a condition, that condition
will be of type STYLE-WARNING and will be signalled by a call to
the function WARN.
Examples:
redefinition of function with different argument list
calls to function with wrong number of arguments
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
Both COMPILE and COMPILE-FILE are allowed to establish a default
condition handler. If such a condition handler is established,
however, it must first resignal the condition to give any
user-established handlers a chance to handle it. If all user error
handlers decline, the default handler may handle the condition in an
implementation-specific way; for example, it might turn errors into
warnings.
% Reference: issue WITH-COMPILATION-UNIT
In some implementations, some kinds of warnings may be deferred until
"the end of compilation"; see WITH-COMPILATION-UNIT.
-------
∂15-May-89 1710 Quinquevirate-mailer Compiler section (4.2)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 May 89 17:10:27 PDT
Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 208862; 15 May 89 20:09:34 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 595464; 15 May 89 20:11:04 EDT
Date: Mon, 15 May 89 20:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Compiler section (4.2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate%sail.stanford.edu@REAGAN.AI.MIT.EDU
In-Reply-To: <8905151042.AA24115@decwrl.dec.com>
Message-ID: <19890516001114.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Indented text is an excerpt from the document being discussed.
I didn't want to include the whole thing in my reply. I hope
this is enough context to locate the points I'm referrring to.
% This paragraph should really conclude with a stronger statement that
% conforming programs must be structured so they will work if implicit
% compilation does take place, but CLtL doesn't come right out and say
% that, and we have never voted on any issue to say that either.
I see no reason not to say that. I think CLtL was intended to imply it,
so I don't see any reason why the drafting committee can't decide to
say it outright. This means only a little more than that a conforming
program can't depend on just when macroexpansion takes place.
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within the
code being compiled are to be treated as lexical or special. The
compiler must treat any binding of a variable that has not been
declared or proclaimed to be SPECIAL as a lexical binding.
- The compiler must process EVAL-WHEN forms that appear lexically within
the program being compiled. Effectively, the compiler must replace
the EVAL-WHEN form with either a PROGN containing the body forms, or
a constant NIL.
Sandra didn't like it when I pointed out that the above two points are
requirements on both the interpreter and the compiler (as of the latest
compiler issues, in the case of EVAL-WHEN) and therefore don't belong
in this section. If 4.1 is the semantics of execution of programs in
general, while 4.2 is the things that are peculiar to compilation,
then they belong in 4.1.
She didn't like it, but didn't convince me I was wrong.
[rpg: There is a complicated issue: Can the compiler assume that the
resulting code in a compile-file situation will be run in the same
Lisp? The same implementation? The same computer? The same type of
computer?
I suggest that we say that the semantics we discuss presumes that the
compiler can assume that when doing compile-file that the resulting
code will be loaded into a fresh copy of the same Lisp.]
I think that is reasonable. Implementations of compile-file can work in
other cases too, if they feel like it, but this is the only case
specified by the standard. I think trying to define precisely what
"the same" means is likely to run into problems, I'd suggest leaving it
with rpg's wording and not trying to be more precise.
However we have to be careful not to rule out the common technique of
compiling a multifile program by compiling the first file, loading the
result, compiling the second file, loading it, etc. It would be a shame
if conformance required rebooting the Lisp between each compilation.
[rpg: the interpreter can assume the same thing, right?
ANYTHING the compiler can assume the interpreter can also assume, since
there is nothing in Common Lisp that mandates any semantic differences
between the compiler and the interpreter. Some implementations only
have one or the other.
- COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at run time.
[rpg: the interpreter can assume the same thing, right?]
I don't think so, or even known what it would mean, because this is a
statement about COMPILE-FILE, not about the compiler. Maybe LOAD of
a source file may assume ....?
[rpg: This is a little curious. Is this talking only about this sort of case:....
Well, this whole section is unclear when it talks about the compile time
environment as to whether it means definitions made in the file being
compiled or definitions made in the Lisp running the compiler, either
before calling COMPILE-FILE or inside EVAL-WHEN COMPILE in the file.
I think it means both. Of course these things when they say "the compiler"
rather than "COMPILE-FILE" also are talking about the COMPILE function
and implicit compilation, for which the compile time environment and the
run time environment are two different states of the same Lisp at different
times. Maybe Sandra should clarify?
* If the form is an EVAL-WHEN form, it is handled according to
the following table:
The formatting of this table is completely destroyed, the headings do
not line up with the columns. To get a narrow enough table, maybe the
columns will have to be labelled with numbers and the headings given
in a caption.
[rpg: I prefer this, because the objects may not be *re*constructed since
they might not have been constructed in the first place. Also, ``instructions''
might never appear, only some collaboration need be implied:
COMPILE-FILE, on the other hand, must produce an output file which
when loaded with LOAD constructs the objects defined by the source
code.]
I prefer this also. The only problem is that the objects aren't always
actually constructed, sometimes they already exist and are just referenced.
It's not clear that fixing that would improve understandability, so leave it.
However, it mandates some rewording of the next paragraph since it is no
longer clear what EQL relationship is being referred to. I offer:
In the case of COMPILE-FILE, we cannot speak of objects constructed by
LOAD of the output file being EQL to objects constructed at compile
time, since the compiled file may be loaded into a different Lisp image
than the one that it was compiled in. This section defines a notion of
"similarity as constants" which relates objects in the the compile time
environment to the corresponding objects in the load time environment.
% Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
% and loader handle interned symbols.
This sentence can't be commented out without replacing it with something.
Commenting it out leaves the discussion of symbols incomplete.
Two arrays are similar as constants if the corresponding values each
of each
For arrays of other dimensions:
other rank
I read through to the end but have no other comments right now.
I might comment on the next revision though.
∂16-May-89 0548 Quinquevirate-mailer conformance
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 16 May 89 05:48:01 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA28475; Tue, 16 May 89 05:48:56 PDT
Message-Id: <8905161248.AA28475@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA28475; Tue, 16 May 89 05:48:56 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 16 May 89 08:24
To: quinquevirate@sail.stanford.edu
Subject: conformance
Since this issue will map directly into section 1.5 of the standard, I thought
you might want to review it before I send it to X3J13. I'll be sending it
out next Monday.
kathy
Issue: CONFORMANCE-POSITION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
6-FEB-89, Version 5 by Chapman
20-FEB-89, Version 6 by Chapman
5-MAY-89, Version 7 by Chapman
Problem Description:
Two ways of defining conformance are in terms of conforming code
and in terms of a conforming implementation. How should our standard
define conformance? What is the relationship between conformance and
portability?
Proposal (CONFORMANCE-POSITION:IMPLEMENTATION-AND-CODE)
The standard presents the syntax and semantics to be implemented by
a conforming implementation. In addition, it levies requirements on
conforming code and documentation.
Definitions:
Code: One or more Common Lisp forms meant to be evaluated.
Processor: A system or mechanism that accepts code as input, prepares
it for execution, and executes the process so defined with data to produce
results.
Implementation-dependent: Possibly differing between processors and not
necessarily defined for any particular processor.
Implementation-defined: Possibly differing between processors, but defined
for any particular processor.
Extension: A facility in the implemented language that is not given in this
standard but that does not cause any ambiguity or contradiction when added
to the language standard.
Conformance:
A processor conforming with the requirements of this standard shall:
1. accept all the features of the language specified in this standard,
with the meanings defined in this standard.
2. not require the inclusion of substitute or additional language elements in
code in order to accomplish a feature of the language that is specified
in this standard.
3. be accompanied by a document that provides a definition of all
implementation-defined features.
4. treat exceptional situations in the manner specified in section 1.4 of
the standard (i.e. the Definitions section. It contains the error terminology.).
5. be accompanied by a document that separately describes any features accepted
by the processor that are prohibited or not specified in this standard.
Such extensions shall be described as being ``extensions to Common Lisp
as specified by ANSI ...''.
6. produce a conformance statement as a consequence of using the processor,
or that statement shall be included in the accompanying documentation.
If the processor conforms in all respects with this standard, the conformance
statement shall be
``<This processor> conforms with the requirements of ANSI <standard number>''
If the processor conforms with some but not all of the requirements of this
standard, then the conformance statement shall be
``<This processor> conforms with the requirements of ANSI <standard number>
with the following exceptions:
<followed by a reference to, or a complete list of, the requirements of
the standard with which the processor does not conform>.
Code conforming with the requirements of this standard shall:
1. use only those features of the language specified in this standard.
2. not rely on any particular interpretation of implementation-dependent
features.
Note that code that conforms with the requirements of this standard
may rely on particular implementation-defined values or features. Also note
that the requirements for conforming code and conforming processors do
not require that the results produced by conforming code are always
the same when processed by a conforming processor. They may be, or they may
differ, depending on the code.
Informally, the basic rules for conformance are as follows:
1. Conforming code uses only the syntax specified in the standard.
2. Conforming code is written in only the sequence specified in the standard.
3. Conforming code is written using only the functions, macros,
special forms, variables, and constants specified in the standard.
4. Conforming implementations provide the functions, macros, special
forms, variables, and constants specified in the standard,
and arrange that they behave in ways
that conform to the specifications of them in the standard.
The definitions of all other functions, macros, or symbols must accompany
the code. Extensions to syntax are not allowed in conforming code.
5. Conformance will not be machine-checkable.
6. Conforming code will only be defined in terms of its structure.
It's possible for a conformal code to
run in all conformal implementations, but to have allowable
implementation-defined behavior that could make it non-portable.
Insofar as we allow options in the standard this will be true.
Portable code is required to produce equivalent results and
observable side effects in all conforming implementations.
Portable code is written using only STANDARD-CHAR-P characters.
Portable code is written using no extra optional keyword arguments.
Rationale:
The standard must contain information about conformance. Only including
requirements that would be placed on implementations, however, leaves
the possibility open that something would be overlooked, and so
implementations may well conform without processing correctly
conforming code.
Current Practice:
CLtL generally describes things in terms of what correct code can
expect, but the document itself levies the requirement on an implementation
to support all the described functionality.
dpANS C also defined conformance in terms of code.
It has further defined both "conforming" and "strictly conforming" code.
Pascal defines conformance in terms of both, PL/I defines conformance in
terms of conforming code only.
Fortran and Ada say that a conforming implementation correctly processes
conforming code. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both code and implementations.
Adoption Cost:
The use of the words "implementation-defined" and "implementation-dependent"
in CLtL and the standard will have to be checked to make sure the uses
and the definitions given above coincide. Any changes that occur as a
result of this check could potentially affect some user code, but it's
unlikely.
Implementations will have to be checked to make sure they conform with the
rules stated above, and conformance statements will have to be added.
Documentation may have to be updated.
Benefits:
This definition will give readers and validators a basis on which to read
the standard.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
The information in this issue was derived from three documents:
the C ANSI standard, the "Proposed Draft Techinical Report-Guidelines on the
preparation of conformity clauses in porogramming languages and Letter Ballot"
(CT22/87-094, ISO/TC97/SC22/WG12 N133 Rev 1, October, 1987), and
"Specification for Computer programming language Pascal" (BS 6192:1982,
UDC 681.3.06 Pascal: 519.682).
∂16-May-89 0748 Quinquevirate-mailer re: Compiler section (4.2)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 May 89 07:48:07 PDT
Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 209082; 16 May 89 10:47:04 EDT
Message-ID: <a#VeG@SAIL.Stanford.EDU>
Date: 16 May 89 0746 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: re: Compiler section (4.2)
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM
CC: quinquevirate%sail.stanford.edu@REAGAN.AI.MIT.EDU
[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Mon, 15 May 89 20:11 EDT.]
Moon writes:
``I don't think so, or even known what it would mean, because this is a
statement about COMPILE-FILE, not about the compiler. Maybe LOAD of
a source file may assume ....?''
[rpg: I'm imagining an implementation strategy in which a separate image
with a compiler compile-file's all input to the ``real Lisp'' and the real
Lisp loads it. You can also imagine that the ``real Lisp'' is clever to
batch up forms to be compiled to the compiler image, making the analogy
to a file more precise. Possibly this is stretching the point. (Also, the
collaboration between these two processes must be tight to provide the
right behavior according to what COMPILE must do.]
Moon writes:
``I prefer this also. The only problem is that the objects aren't always
actually constructed, sometimes they already exist and are just referenced.
It's not clear that fixing that would improve understandability, so leave it.''
[rpg: Quite right. How about this:
COMPILE-FILE, on the other hand, must produce an output file which when
loaded with LOAD constructs or references or both the objects defined by
the source code.]
∂16-May-89 1035 Quinquevirate-mailer conformance
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 May 89 10:35:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 595810; 16 May 89 13:21:04 EDT
Date: Tue, 16 May 89 13:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: conformance
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@SAIL.STANFORD.EDU
In-Reply-To: <8905161248.AA28475@decwrl.dec.com>
Message-ID: <19890516172114.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'm not a conformance expert, but this seems basically okay to me.
I just have a couple of criticisms. Indented text is excerpted from
your message.
Extensions to syntax are not allowed in conforming code.
This is ambiguous. It could be read to mean that conforming code is not
permitted to define reader macros. However, what I think you meant is
that conforming code is not permitted to depend on
implementation-provided syntax extensions. Is that what you meant?
How is that different from:
1. Conforming code uses only the syntax specified in the standard.
In fact, that statement might also be read to rule out definition of
reader macros by conforming code. You should treat syntax the same
as functions, macros, etc., i.e. conforming code must use only the
things defined in the standard plus things whose definition accompanies
the program, where "things" includes syntax as well as defined names.
6. Conforming code will only be defined in terms of its structure.
as contrasted with what? Its behavior? Say explicitly.
Perhaps the whole "informal rules" section needs a little more writing
to use more parallel constructions and avoid ambiguities and loopholes.
Even though it's informal it should not be ambiguous.
Portable code is required to produce equivalent results and
observable side effects in all conforming implementations.
Portable code is written using only STANDARD-CHAR-P characters.
Portable code is written using no extra optional keyword arguments.
The term "portable" is never defined. Is this a definition? (In which
case move it to the definitions section earlier in the proposal.) If this
is not a definition, but a restriction on something whose definition is
different, add an explicit definition. Also I don't understand what the
last sentence about "extra optional keyword arguments" is supposed to
refer to, nor how portable and conforming code differ in this respect.
Rationale:
The standard must contain information about conformance. Only including
requirements that would be placed on implementations, however, leaves
the possibility open that something would be overlooked, and so
implementations may well conform without processing correctly
conforming code.
Sorry, I couldn't understand the second sentence at all. I couldn't
even parse it.
∂16-May-89 1036 Quinquevirate-mailer re: Compiler section (4.2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 May 89 10:35:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 595794; 16 May 89 12:47:49 EDT
Date: Tue, 16 May 89 12:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: re: Compiler section (4.2)
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: quinquevirate@SAIL.STANFORD.EDU
In-Reply-To: <a#VeG@SAIL.Stanford.EDU>
Message-ID: <19890516164758.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 16 May 89 0746 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at run time.
[rpg: the interpreter can assume the same thing, right?]
Moon writes:
``I don't think so, or even known what it would mean, because this is a
statement about COMPILE-FILE, not about the compiler. Maybe LOAD of
a source file may assume ....?''
[rpg: I'm imagining an implementation strategy in which a separate image
with a compiler compile-file's all input to the ``real Lisp'' and the real
Lisp loads it. You can also imagine that the ``real Lisp'' is clever to
batch up forms to be compiled to the compiler image, making the analogy
to a file more precise. Possibly this is stretching the point. (Also, the
collaboration between these two processes must be tight to provide the
right behavior according to what COMPILE must do.]
I don't think an analogy to a file is good enough if we're going to give
files such prominence that block compilation within one file is allowed but
across files is not allowed, which is my interpretation of what Sandra's
text quoted above says. I think I'd be happiest if we just left this part
referring to COMPILE-FILE as written. The implementation strategy you're
imagining might have to disable block compilation when compiling things
sent over from the Lisp, but I see no harm in that.
Moon writes:
``I prefer this also. The only problem is that the objects aren't always
actually constructed, sometimes they already exist and are just referenced.
It's not clear that fixing that would improve understandability, so leave it.''
[rpg: Quite right. How about this:
COMPILE-FILE, on the other hand, must produce an output file which when
loaded with LOAD constructs or references or both the objects defined by
the source code.]
Good. (I'd use "and/or" to avoid saying "or both"; either way is okay.)
∂16-May-89 1110 Quinquevirate-mailer re: Compiler section (4.2)
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM
CC: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message sent Tue, 16 May 89 12:47 EDT.]
``...block compilation within one file is allowed but
across files is not allowed, which is my interpretation of what Sandra's
text quoted above says.''
Seems that block compilation should be on a compilation-unit
basis, don't you think? We can leave the original text as is.
I was using ``or both'' to avoid saying ``and/or''. I don't care
either.
-rpg-
∂16-May-89 1113 Quinquevirate-mailer re: Compiler section (4.2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 May 89 11:13:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 595846; 16 May 89 14:13:27 EDT
Date: Tue, 16 May 89 14:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: re: Compiler section (4.2)
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: quinquevirate@SAIL.STANFORD.EDU
In-Reply-To: <m#Ydr@SAIL.Stanford.EDU>
Message-ID: <19890516181340.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 16 May 89 1110 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Seems that block compilation should be on a compilation-unit
basis, don't you think?
That's what I wanted WITH-COMPILATION-UNIT to be, but I couldn't
find anybody to agree with me.
∂16-May-89 1133 Quinquevirate-mailer Compiler section (4.2)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 16 May 89 11:33:51 PDT
Received: from fafnir.think.com by Think.COM; Tue, 16 May 89 14:33:26 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 16 May 89 14:33:16 EDT
Received: from joplin.think.com by verdi.think.com; Tue, 16 May 89 14:33:03 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Tue, 16 May 89 14:33:00 EDT
Date: Tue, 16 May 89 14:33:00 EDT
Message-Id: <8905161833.AA00368@joplin.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: RPG@sail.stanford.edu, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 16 May 89 12:47 EDT <19890516164758.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Compiler section (4.2)
[rpg: Quite right. How about this:
COMPILE-FILE, on the other hand, must produce an output file which when
loaded with LOAD constructs or references or both the objects defined by
the source code.]
Good. (I'd use "and/or" to avoid saying "or both"; either way is okay.)
Maybe he meant "constructs or references or boths the objects".
∂16-May-89 1138 Quinquevirate-mailer Compiler section (4.2)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 16 May 89 11:38:01 PDT
Received: from fafnir.think.com by Think.COM; Tue, 16 May 89 14:37:27 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 16 May 89 14:37:16 EDT
Received: from joplin.think.com by verdi.think.com; Tue, 16 May 89 14:37:04 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Tue, 16 May 89 14:37:02 EDT
Date: Tue, 16 May 89 14:37:02 EDT
Message-Id: <8905161837.AA00373@joplin.think.com>
To: RPG@sail.stanford.edu
Cc: Moon@stony-brook.scrc.symbolics.com, quinquevirate@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 16 May 89 1110 PDT <m#Ydr@SAIL.Stanford.EDU>
Subject: Compiler section (4.2)
I was using ``or both'' to avoid saying ``and/or''. I don't care
either.
Since nobody seems to care, I can safely summarize the result as:
Use both or and/or or both.
∂16-May-89 1457 Quinquevirate-mailer checked out status (5/16)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 16 May 89 14:57:15 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14122; Tue, 16 May 89 14:58:14 PDT
Message-Id: <8905162158.AA14122@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA14122; Tue, 16 May 89 14:58:14 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 16 May 89 15:49
To: quinquevirate@sail.stanford.edu
Subject: checked out status (5/16)
Section Who has Date out Status
1.1 KC Done
1.2 KC
1.3 KC
1.4 KC
1.5 KC
1.6 KC
2.1 KC
2.2 Moon 5/5/89 Second iteration
2.3 RPG 5/5/89
2.4 RPG 5/5/89
2.5 RPG 5/5/89
3.1 Masinter 5/5/89
3.2 Masinter 5/5/89
3.3 Masinter 5/5/89
3.4 Masinter 5/5/89
4.1 Moon 5/5/89 Second iteration
4.2 RPG 5/16/89 Reviewing Sandra's document
5.1 RPG 4/7/89
5.2 Masinter 4/7/89
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 5/5/89
Glossary RPG 5/16/89 Extensive KMP review
CLOS RPG 5/2/89
PREDICATES Masinter 5/3/89
STRINGS Masinter 5/3/89
SEQUENCES Masinter 5/3/89
LISTS Masinter 5/3/89
NUMBERS Masinter 5/3/89
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/89
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC
STREAMS KC
FILE KC
CONTROL KC
PROGRAM KC
MISC KC
ERRORS Moon 5/4/89
MACROS Moon 5/4/89
PACKAGES Moon 5/4/89
CHARACTERS Moon 5/4/89
EVALUATOR Moon 5/4/89
∂18-May-89 1304 Quinquevirate-mailer checked out as of 5/18
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 May 89 13:04:53 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA01264; Thu, 18 May 89 13:05:49 PDT
Message-Id: <8905182005.AA01264@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA01264; Thu, 18 May 89 13:05:49 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 May 89 15:52
To: quinquevirate@sail.stanford.edu
Subject: checked out as of 5/18
Section Who has Date out Status
1.1 KC Done
1.2 KC Updating as necessary
1.3 KC Updating as necessary
1.4 KC Updating as necessary
1.5 KC Updating as necessary
1.6 KC Updating as necessary
2.1 KC Updating as necessary
2.2 Moon 5/5/89 Second iteration
2.3 RPG 5/5/89 Reviewing?
2.4 RPG 5/5/89 Reviewing?
2.5 RPG 5/5/89 Reviewing?
3.1 Moon 5/5/89 First review
3.2 Moon 5/5/89 First review
3.3 Moon 5/5/89 First review
3.4 Moon 5/5/89 First review
4.1 Moon 5/5/89 Second iteration
4.2 RPG 5/16/89 Reviewing Sandra's document
5.1 RPG 4/7/89 Rewriting?
5.2 Masinter 4/7/89 Reviewing?
5.3 Masinter 4/7/89 Reviewing?
5.4 KC Masinter is to review
6.1 RPG 5/5/89 Reviewing?
Glossary RPG 5/16/89 Extensive KMP + Moon review
For all of the following "sections" that KC has,
comments from other reviewers are being inserted, but they can
be made available to the person who is to review them anytime.
Also, if you are not reviewing the parts checked out to you, you
can check them back in and I can include the compiler and character
issues in those sections.
CLOS RPG 5/2/89 Reviewing?
PREDICATES KC Masinter is to review
STRINGS KC Masinter is to review
SEQUENCES KC Masinter is to review
LISTS KC Masinter is to review
NUMBERS KC Masinter is to review
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/89
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC Masinter is to review
STREAMS KC Masinter is to review
FILE KC Masinter is to review
CONTROL KC Masinter is to review
PROGRAM KC Masinter is to review
MISC KC Masinter is to review
ERRORS Moon 5/4/89
MACROS Moon 5/4/89 First review
PACKAGES Moon 5/4/89
CHARACTERS Moon 5/4/89
EVALUATOR Moon 5/4/89
∂22-May-89 1248 Quinquevirate-mailer Sections 2.3 and 2.5
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 May 89 12:46:43 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 598838; 22 May 89 15:38:21 EDT
Date: Mon, 22 May 89 15:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sections 2.3 and 2.5
To: Richard P. Gabriel <rpg@lucid.com>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8904221836.AA01737@challenger>
Message-ID: <19890522194239.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Sat, 22 Apr 89 11:36:27 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Of the three approaches Moon suggests, I favor a combination of
bringing some stuff into the main specification from the prototype
chapter 3 and flagging the rest as places for future extension.
This conversation seems to have flagged. Out of inertia, I favor
minimizing changes to the language rather than trying to bring in
parts of chapter 3, even though if we did the extra work to rethink
the boundary between chapter 2 and chapter 3 we would probably end
up with a better language.
I feel that the largest exposures we have are readers (but not
writers) for some things like these (this list suggested by Jonl):
class-direct-supers, class-direct-subclasses, class-direct-slots,
class-slots, class-direct-methods, class-precedence-list,
class-forward-referenced-supers, class-no-of-instance-slots,
method-function, method-generic-function, method-arglist,
method-qualifiers, method-specializers, generic-function-name,
generic-function-methods, generic-function-discriminator-code,
generic-function-lambda-list, slotd-name, slotd-allocation,
slotd-initform, slotd-initargs, and slotd-type.
method-qualifiers is already in chapter 2. The slotd- ones would
require also bringing slotd objects in chapter 2 (currently they
aren't), which I'm afraid of because the chapter 3 definition of slotd
objects seems to still be changing. The ones that return lists of slotd
objects can't be used if we don't have slotd objects.
class-forward-referenced-supers is too controversial as well as a bad
name. class-no-of-instance-slots seems unnecessary and is a bad name.
generic-function-discriminator-code is too implementation-dependent.
method-function is too implementation-dependent.
The remaining ones would be okay, however I haven't found the time to
figure out whether they would make a complete and consistent set.
That's class-direct-supers [again a bad name], class-direct-subclasses,
class-direct-methods, class-precedence-list, method-generic-function,
method-arglist [should be method-lambda-list], method-specializers,
generic-function-name, generic-function-methods, and
generic-function-lambda-list.
Also we are exposed on the inability to make methods for add-method to
use. These are the places where I would consider trying move something
into the main specification.
I agree about the add-method problem. Since the macroexpansion of defmethod
in chapter 3 is still in flux, I think it might be unwise to try to bring
into chapter 2 a way to construct the argument to add-method. It might be
better to get rid of add-method. I haven't found the time to figure out
whether getting rid of add-method would break anything. Maybe it's better
just to flag add-method as a place for future expansion and not change
the language.
I looked through the summary on pages 2-5 and 2-6 of 88-002R and the following
seemed not clearly justified as chapter 2 rather than chapter 3. Again I
can't claim to have evaluated the possible danger of kicking these out to
chapter 3.
add-method
compute-applicable-methods
ensure-generic-function
Everything else in chapter 2 clearly belongs in the programmer interface
rather than the metaobjects level.
Also it's perhaps time to bring up the question of whether we really want
the ANSI standard to include generic-flet, generic-function, generic-labels,
and with-added-methods. While these nicely round out the language, I have
so far been unable to discover any CLOS implementation that implements them
or says it plans to implement them. Putting them in the standard is
probably premature in the absence of any practice.
Someone [probably KMP] writes:
``p.2-3, para.3: Without meta objects one can't create anonymous
classes and improper class names, so much of this paragraph is
currently irrelevant. Keep the first two sentences and the last
sentence, delete the rest. [I think we should keep it anyway, but
flag it as a framework for future extensions --Moon]''
Hm, I thought CLASS-NAME was a SETFable place, as was FIND-CLASS, but
I guess that isn't true as it currently stands.
class-name and find-class are both documented as setf'able in 88-002R.
There's no way to make an argument for (setf find-class) except by
getting a named class defined by defclass, but still this is enough to
create improper class names and even anonymous classes in a roundabout
way. So most likely the whole paragraph should be kept (I don't have
a copy of it here to recheck what it said).
``p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
the current metaobject-free standard.''
Well, there are various metaclasses now (structure-class and
standard-class), and there are some places that talk about compatible
metaclasses. I can't believe it's reasonable to flush all mention of
metaclasses because you cannot create them. (Actually, you can, but it
isn't likely that you can do anything useful with them. For example,
you can do (defclass random-metaclass (standard-class)) and then
proceed to make instances of it which are hardly distinguishable from
ordinary standard classes.)
Agreed.
``p.2-5, bullet 3: changing "is shared by instances" to
"is shared by all instances" would be clearer.''
This is fine. Kathy, can you do this?
Agreed.
``p.2-5: Delete the 3-line inheritance section. This section has been
reorganized into nonexistence.
p.2-5: Inheritance of Class Options should come after the class
precedence list section.''
Ok. Kathy, can you do this?
``p.2-9, Redefining Classes, Third paragraph: The CLOS spec says when
slots aren't updated, X3J13 says when they are updated. X3J13 doesn't
mention anything about changes to ordering. [How come this spec.
doesn't say exactly the same thing as 88-002R here? --Moon]''
I don't quite get this. I have the Feb 14 X3J13 draft here (my March 21
draft is at work), and both the Feb 14 draft and 88-002R say this:
``Note that redefining a class may cause slots to be added or deleted.
If a class is redefined in a way that changes the set of local slots
accessible in instances, the instances will be updated. It is
implementation dependent whether instances are updated if a class is
redefined in a way that does not change the set of local slots
accessible in instances.''
On the other hand, this paragraph appears on page 2-47 not 2-9, so it's
hard to tell whether we are all talking about the same thing.
I don't have the thing here, but I think we're not al talking about the same
thing and on p.2-9 there was some text that needs to be made consistent
with the other parts of the document.
``In several of these paragraphs, references are made to the "old class"
and the "new class". It would be clearer to say "the old class
definition" and "the new class definition" since it's still the same
class object after the redefinition.''
I think there is ample distinction made in the first paragraph of this section
between the class object and the class. This section and others like it
are difficult enough to understand without extra words like ``definition''
being thrown in where that doesn't really aid understanding. Consider how
you would rewrite this using ``definition'':
``The value of a slot that is specified as shared both in the old class
and in the new class is retained. If such a shared slot was unbound
in the old class, it will be unbound in the new class. Slots that
were local in the old class and that are shared in the new class are
initialized. Newly added shared slots are initialized.''
Here is a try:
``The value of a slot that is specified as shared both by the old
class definition and by the new class definition is retained. If such
a shared slot was unbound in the class specified by the old
definition, it will be unbound in the class specified by the new
definition. Slots that were specified as local by the old class
definition and that are specified as shared by the new class are
initialized. Newly added shared slots are initialized.''
I'm not sure that this slightly more precise paragraph says anything
more than the original, and it is a lot harder to understand.
It just seems longer to me, and not harder to understand for any
reason other than the extra length. However I really have no
opinion on this issue. BTW I was unaware that there was _any_
distinction between "the class object" and "the class."
Finally, the classes might be EQ, but they are not equal as classes.
(1 2 3) and (a b c d e) might be EQ, but one is the old list and the
other is the new list, if one was derived from the other via
replacement.
Well, as soon as time-varying objects are brought into the picture,
equality becomes ten times as hard to talk about.
∂22-May-89 1248 Quinquevirate-mailer Sections 2.3 and 2.5
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 May 89 12:46:43 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 598839; 22 May 89 15:39:14 EDT
Date: Mon, 22 May 89 15:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sections 2.3 and 2.5
To: Richard P. Gabriel <rpg@lucid.com>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8904221836.AA01737@challenger>
Supersedes: <19890522194239.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Comments: Remove my misattribution of some comments to KMP
Message-ID: <19890522194337.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Sat, 22 Apr 89 11:36:27 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Of the three approaches Moon suggests, I favor a combination of
bringing some stuff into the main specification from the prototype
chapter 3 and flagging the rest as places for future extension.
This conversation seems to have flagged. Out of inertia, I favor
minimizing changes to the language rather than trying to bring in
parts of chapter 3, even though if we did the extra work to rethink
the boundary between chapter 2 and chapter 3 we would probably end
up with a better language.
I feel that the largest exposures we have are readers (but not
writers) for some things like these (this list suggested by Jonl):
class-direct-supers, class-direct-subclasses, class-direct-slots,
class-slots, class-direct-methods, class-precedence-list,
class-forward-referenced-supers, class-no-of-instance-slots,
method-function, method-generic-function, method-arglist,
method-qualifiers, method-specializers, generic-function-name,
generic-function-methods, generic-function-discriminator-code,
generic-function-lambda-list, slotd-name, slotd-allocation,
slotd-initform, slotd-initargs, and slotd-type.
method-qualifiers is already in chapter 2. The slotd- ones would
require also bringing slotd objects in chapter 2 (currently they
aren't), which I'm afraid of because the chapter 3 definition of slotd
objects seems to still be changing. The ones that return lists of slotd
objects can't be used if we don't have slotd objects.
class-forward-referenced-supers is too controversial as well as a bad
name. class-no-of-instance-slots seems unnecessary and is a bad name.
generic-function-discriminator-code is too implementation-dependent.
method-function is too implementation-dependent.
The remaining ones would be okay, however I haven't found the time to
figure out whether they would make a complete and consistent set.
That's class-direct-supers [again a bad name], class-direct-subclasses,
class-direct-methods, class-precedence-list, method-generic-function,
method-arglist [should be method-lambda-list], method-specializers,
generic-function-name, generic-function-methods, and
generic-function-lambda-list.
Also we are exposed on the inability to make methods for add-method to
use. These are the places where I would consider trying move something
into the main specification.
I agree about the add-method problem. Since the macroexpansion of defmethod
in chapter 3 is still in flux, I think it might be unwise to try to bring
into chapter 2 a way to construct the argument to add-method. It might be
better to get rid of add-method. I haven't found the time to figure out
whether getting rid of add-method would break anything. Maybe it's better
just to flag add-method as a place for future expansion and not change
the language.
I looked through the summary on pages 2-5 and 2-6 of 88-002R and the following
seemed not clearly justified as chapter 2 rather than chapter 3. Again I
can't claim to have evaluated the possible danger of kicking these out to
chapter 3.
add-method
compute-applicable-methods
ensure-generic-function
Everything else in chapter 2 clearly belongs in the programmer interface
rather than the metaobjects level.
Also it's perhaps time to bring up the question of whether we really want
the ANSI standard to include generic-flet, generic-function, generic-labels,
and with-added-methods. While these nicely round out the language, I have
so far been unable to discover any CLOS implementation that implements them
or says it plans to implement them. Putting them in the standard is
probably premature in the absence of any practice.
Someone writes:
[it wasn't KMP]
``p.2-3, para.3: Without meta objects one can't create anonymous
classes and improper class names, so much of this paragraph is
currently irrelevant. Keep the first two sentences and the last
sentence, delete the rest. [I think we should keep it anyway, but
flag it as a framework for future extensions --Moon]''
Hm, I thought CLASS-NAME was a SETFable place, as was FIND-CLASS, but
I guess that isn't true as it currently stands.
class-name and find-class are both documented as setf'able in 88-002R.
There's no way to make an argument for (setf find-class) except by
getting a named class defined by defclass, but still this is enough to
create improper class names and even anonymous classes in a roundabout
way. So most likely the whole paragraph should be kept (I don't have
a copy of it here to recheck what it said).
``p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
the current metaobject-free standard.''
Well, there are various metaclasses now (structure-class and
standard-class), and there are some places that talk about compatible
metaclasses. I can't believe it's reasonable to flush all mention of
metaclasses because you cannot create them. (Actually, you can, but it
isn't likely that you can do anything useful with them. For example,
you can do (defclass random-metaclass (standard-class)) and then
proceed to make instances of it which are hardly distinguishable from
ordinary standard classes.)
Agreed.
``p.2-5, bullet 3: changing "is shared by instances" to
"is shared by all instances" would be clearer.''
This is fine. Kathy, can you do this?
Agreed.
``p.2-5: Delete the 3-line inheritance section. This section has been
reorganized into nonexistence.
p.2-5: Inheritance of Class Options should come after the class
precedence list section.''
Ok. Kathy, can you do this?
``p.2-9, Redefining Classes, Third paragraph: The CLOS spec says when
slots aren't updated, X3J13 says when they are updated. X3J13 doesn't
mention anything about changes to ordering. [How come this spec.
doesn't say exactly the same thing as 88-002R here? --Moon]''
I don't quite get this. I have the Feb 14 X3J13 draft here (my March 21
draft is at work), and both the Feb 14 draft and 88-002R say this:
``Note that redefining a class may cause slots to be added or deleted.
If a class is redefined in a way that changes the set of local slots
accessible in instances, the instances will be updated. It is
implementation dependent whether instances are updated if a class is
redefined in a way that does not change the set of local slots
accessible in instances.''
On the other hand, this paragraph appears on page 2-47 not 2-9, so it's
hard to tell whether we are all talking about the same thing.
I don't have the thing here, but I think we're not al talking about the same
thing and on p.2-9 there was some text that needs to be made consistent
with the other parts of the document.
``In several of these paragraphs, references are made to the "old class"
and the "new class". It would be clearer to say "the old class
definition" and "the new class definition" since it's still the same
class object after the redefinition.''
I think there is ample distinction made in the first paragraph of this section
between the class object and the class. This section and others like it
are difficult enough to understand without extra words like ``definition''
being thrown in where that doesn't really aid understanding. Consider how
you would rewrite this using ``definition'':
``The value of a slot that is specified as shared both in the old class
and in the new class is retained. If such a shared slot was unbound
in the old class, it will be unbound in the new class. Slots that
were local in the old class and that are shared in the new class are
initialized. Newly added shared slots are initialized.''
Here is a try:
``The value of a slot that is specified as shared both by the old
class definition and by the new class definition is retained. If such
a shared slot was unbound in the class specified by the old
definition, it will be unbound in the class specified by the new
definition. Slots that were specified as local by the old class
definition and that are specified as shared by the new class are
initialized. Newly added shared slots are initialized.''
I'm not sure that this slightly more precise paragraph says anything
more than the original, and it is a lot harder to understand.
It just seems longer to me, and not harder to understand for any
reason other than the extra length. However I really have no
opinion on this issue. BTW I was unaware that there was _any_
distinction between "the class object" and "the class."
Finally, the classes might be EQ, but they are not equal as classes.
(1 2 3) and (a b c d e) might be EQ, but one is the old list and the
other is the new list, if one was derived from the other via
replacement.
Well, as soon as time-varying objects are brought into the picture,
equality becomes ten times as hard to talk about.
∂22-May-89 1416 Quinquevirate-mailer checked out as of 5/22
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 22 May 89 14:16:44 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA23492; Mon, 22 May 89 14:17:48 PDT
Message-Id: <8905222117.AA23492@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA23492; Mon, 22 May 89 14:17:48 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 22 May 89 17:11
To: quinquevirate@sail.stanford.edu
Subject: checked out as of 5/22
Section Who has Date out Status
1.1 KC Done
1.2 KC Updating as necessary
1.3 KC Updating as necessary
1.4 KC Updating as necessary
1.5 KC Updating as necessary
1.6 KC Updating as necessary
2.1 KC Updating as necessary
2.2 KC Done
2.3 RPG 5/5/89 Reviewing?
2.4 RPG 5/5/89 Reviewing?
2.5 RPG 5/5/89 Reviewing?
3.1 KC Moon/Masinter to review
3.2 KC Moon/Masinter to review
3.3 KC Moon/Masinter to review
3.4 KC Moon/Masinter to review
4.1 Moon 5/5/89 Second iteration
4.2 RPG 5/16/89 Reviewing Sandra's document
5.1 RPG 4/7/89 Rewriting?
5.2 Masinter 4/7/89 Reviewing?
5.3 Masinter 4/7/89 Reviewing?
5.4 KC Masinter is to review
6.1 RPG 5/5/89 Reviewing?
Glossary RPG 5/16/89 Extensive KMP + Moon review
For all of the following "sections" that KC has,
comments from other reviewers are being inserted, but they can
be made available to the person who is to review them anytime.
Also, if you are not reviewing the parts checked out to you, you
can check them back in and I can include the compiler and character
issues in those sections.
CLOS RPG 5/2/89 Reviewing?
PREDICATES KC Masinter is to review
STRINGS KC Masinter is to review
SEQUENCES KC Masinter is to review
LISTS KC Masinter is to review
NUMBERS KC Masinter is to review
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/89
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC Masinter is to review
STREAMS KC Masinter is to review
FILE KC Masinter is to review
CONTROL KC Masinter is to review
PROGRAM KC Masinter is to review
MISC KC Masinter is to review
ERRORS KC Moon is to review
MACROS KC Done
PACKAGES KC Moon is to review
CHARACTERS KC Moon is to review
EVALUATOR KC Moon is to review